According to OpenMP 5.0, if clause can be used in parallel for simd directive. If condition in the if clause if false, the non-vectorized version of the
loop must be executed.
See PR43425:
https://bugs.llvm.org/show_bug.cgi?id=43425
When writing profile data on Windows we were opening profile file with
exclusive read/write access.
In case we are trying to write to the file from multiple processes
simultaneously, subsequent calls to CreateFileA would return
INVALID_HANDLE_VALUE.
To fix this, I changed to open without exclusive access and then take a
lock.
Patch by Michael Holman!
Differential revision: https://reviews.llvm.org/D70330
The asssertion that was added does not hold,
breaks on test-suite/MultiSource/Applications/SPASS/analyze.c
Will reduce the testcase and revisit.
This reverts commit 9872ea4ed1, 870f3542d3.
This replaces the A32 NEON vqadds, vqaddu, vqsubs and vqsubu intrinsics
with the target independent sadd_sat, uadd_sat, ssub_sat and usub_sat.
This helps generate vqadds from standard IR nodes, which might be
produced from the vectoriser. The old variants are removed in the
process.
Differential Revision: https://reviews.llvm.org/D69350
In order to simplify implementation we are moving add space
deduction into Sema while constructing variable declaration
and on template instantiation. Pointee are deduced to generic
addr space during creation of types.
This commit also
- fixed addr space dedution for auto type;
- factors out in a separate helper function OpenCL specific
logic from type diagnostics in var decl.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65744
Summary:
Implicit Conversion Sanitizer is *almost* feature complete.
There aren't *that* much unsanitized things left,
two major ones are increment/decrement (this patch) and bit fields.
As it was discussed in
[[ https://bugs.llvm.org/show_bug.cgi?id=39519 | PR39519 ]],
unlike `CompoundAssignOperator` (which is promoted internally),
or `BinaryOperator` (for which we always have promotion/demotion in AST)
or parts of `UnaryOperator` (we have promotion/demotion but only for
certain operations), for inc/dec, clang omits promotion/demotion
altogether, under as-if rule.
This is technically correct: https://rise4fun.com/Alive/zPgD
As it can be seen in `InstCombineCasts.cpp` `canEvaluateTruncated()`,
`add`/`sub`/`mul`/`and`/`or`/`xor` operators can all arbitrarily
be extended or truncated:
901cd3b3f6/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp (L1320-L1334)
But that has serious implications:
1. Since we no longer model implicit casts, do we pessimise
their AST representation and everything that uses it?
2. There is no demotion, so lossy demotion sanitizer does not trigger :]
Now, i'm not going to argue about the first problem here,
but the second one **needs** to be addressed. As it was stated
in the report, this is done intentionally, so changing
this in all modes would be considered a penalization/regression.
Which means, the sanitization-less codegen must not be altered.
It was also suggested to not change the sanitized codegen
to the one with demotion, but i quite strongly believe
that will not be the wise choice here:
1. One will need to re-engineer the check that the inc/dec was lossy
in terms of `@llvm.{u,s}{add,sub}.with.overflow` builtins
2. We will still need to compute the result we would lossily demote.
(i.e. the result of wide `add`ition/`sub`traction)
3. I suspect it would need to be done right here, in sanitization.
Which kinda defeats the point of
using `@llvm.{u,s}{add,sub}.with.overflow` builtins:
we'd have two `add`s with basically the same arguments,
one of which is used for check+error-less codepath and other one
for the error reporting. That seems worse than a single wide op+check.
4. OR, we would need to do that in the compiler-rt handler.
Which means we'll need a whole new handler.
But then what about the `CompoundAssignOperator`,
it would also be applicable for it.
So this also doesn't really seem like the right path to me.
5. At least X86 (but likely others) pessimizes all sub-`i32` operations
(due to partial register stalls), so even if we avoid promotion+demotion,
the computations will //likely// be performed in `i32` anyways.
So i'm not really seeing much benefit of
not doing the straight-forward thing.
While looking into this, i have noticed a few more LLVM middle-end
missed canonicalizations, and filed
[[ https://bugs.llvm.org/show_bug.cgi?id=44100 | PR44100 ]],
[[ https://bugs.llvm.org/show_bug.cgi?id=44102 | PR44102 ]].
Those are not specific to inc/dec, we also have them for
`CompoundAssignOperator`, and it can happen for normal arithmetics, too.
But if we take some other path in the patch, it will not be applicable
here, and we will have most likely played ourselves.
TLDR: front-end should emit canonical, easy-to-optimize yet
un-optimized code. It is middle-end's job to make it optimal.
I'm really hoping reviewers agree with my personal assessment
of the path this patch should take..
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44054 | PR44054 ]].
Reviewers: rjmccall, erichkeane, rsmith, vsk
Reviewed By: erichkeane
Subscribers: mehdi_amini, dexonsmith, cfe-commits, #sanitizers, llvm-commits, aaron.ballman, t.p.northover, efriedma, regehr
Tags: #llvm, #clang, #sanitizers
Differential Revision: https://reviews.llvm.org/D70539
Summary:
This avoids leaking PCH files if editors don't use the LSP shutdown protocol.
This is one fix for https://github.com/clangd/clangd/issues/209
(Though I think we should *also* be unlinking the files)
Reviewers: kadircet, jfb
Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, jfb, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70684
This is a follow-up discussed in D70495 thread.
The current logic is unusual for llvm-readobj. It doesn't print predecessors
list when it is empty. This is not good for machine parsers.
D70495 had to add this condition during refactoring to reduce amount of changes,
in tests, because the original code also had a similar logic.
Now seems it is time to get rid of it. This patch does it.
Differential revision: https://reviews.llvm.org/D70717
Use UTF-8 for communication with clang-format and convert the
replacements offset/length to characters position/count.
Internally VisualStudio.Text.Editor.IWpfTextView use sequence of Unicode
characters encoded using UTF-16 and use characters position/count for
manipulating text.
Resolved "Error while running clang-format: Specified argument was out
of the range of valid values. Parameter name: replaceSpan".
Patch by empty2fill!
Differential revision: https://reviews.llvm.org/D70633
Summary:
All these functions are unused from what I can see. Unless I'm missing something here, this code
can go the way of the Dodo.
Reviewers: labath
Reviewed By: labath
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70770
The third parameter to Streamer.EmitSymbolValue() is "bool
IsSectionRelative = false".
For ELF, these debug sections are mapped to address zero, so a normal,
absolute address relocation works just fine, but COFF needs a section
relative relocation, and COFF is the only target where
needsDwarfSectionOffsetDirective() returns true. This matches how
EmitSymbolValue is called elsewhere in the same source file.
Differential Revision: https://reviews.llvm.org/D70661
InitializeContext is useful for allocating a (potentially variable
size) CONTEXT struct in an unaligned byte buffer. In this case, we
already have a fixed size CONTEXT we want to initialize, and we only
used this as a very roundabout way of zero initializing it.
Instead just memset the CONTEXT we have, and set the ContextFlags field
manually.
This matches how it is done in NativeRegisterContextWindows_*.cpp.
This also makes LLDB run successfully in Wine (for a trivial tested
case at least), as Wine hasn't implemented the InitializeContext
function.
Differential Revision: https://reviews.llvm.org/D70742
This reapplies: 8ff85ed905
Original commit message:
As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there.
This change doesn't include any change to move from selection dag to fast isel
and that will come with other numbers that should help inform that decision.
There also haven't been any real debuggability studies with this pipeline yet,
this is just the initial start done so that people could see it and we could start
tweaking after.
Test updates: Outside of the newpm tests most of the updates are coming from either
optimization passes not run anymore (and without a compelling argument at the moment)
that were largely used for canonicalization in clang.
Original post:
http://lists.llvm.org/pipermail/llvm-dev/2019-April/131494.html
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65410
This reverts commit c9ddb02659.
http://45.33.8.238/win/3052/step_6.txt
C:\src\llvm-project\clang\test\Preprocessor\file_test.c:9:11: error: CHECK: expected string not found in input
// CHECK: filename: "/UNLIKELY_PATH/empty{{/|\\\\}}file_test.c"
^
<stdin>:1:1: note: scanning from here
^
<stdin>:1:28: note: possible intended match here
^
When selecting the set of default sanitizers, don't fail for unknown
architectures. This may be the case e.g. with x86_64-unknown-fuchsia
-m32 target that's used to build the bootloader.
Differential Revision: https://reviews.llvm.org/D70747
Current EvalInfo ctor causes EnableNewConstInterp to be true even though
it is supposed to be false on MSVC 2017. This is because a virtual function
getLangOpts() is called in member initializer lists, whereas on MSVC
member ctors are called before function virtual function pointers are
initialized.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D70729
Summary: This will be enhanced in a follow up to add strict fp support
Reviewers: efriedma
Reviewed By: efriedma
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70751
The previous data had the same length with compression levels 1 and 6
for zlib 1.2.8. Adjust the test to work for this library version. I've
also tested this with zlib 1.2.7 and zlib 1.2.11.
Summary:
This is NFC code clean work after D67088. In that patch, we extend loop instructions prep for ds/dq form.
This patch only changes the file name PPCLoopPreIncPrep.cpp to PPCLoopInstrFormPrep.cpp for better reviewing of the content change of file PPCLoopInstrFormPrep.cpp.
Reviewers: #powerpc, nemanjai, steven.zhang, shchenz
Reviewed By: #powerpc, shchenz
Subscribers: wuzish, mgorny, hiraditya, kbarton, shchenz, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70716
It is tricky to use replace_path_prefix correctly on Windows which uses
backslashes as native path separators. Switch back to the old approach
(startswith is not ideal) to appease build bots for now.
GCC 8 implements -fmacro-prefix-map. Like -fdebug-prefix-map, it replaces a string prefix for the __FILE__ macro.
-ffile-prefix-map is the union of -fdebug-prefix-map and -fmacro-prefix-map
Reviewed By: rnk, Lekensteyn, maskray
Differential Revision: https://reviews.llvm.org/D49466
This is correct for any value including NaN/inf.
We don't have this fold directly in the backend either,
but x86 manages to get it after converting things to bitops.
There are a couple of bugs with the sc, scs, ll, lld instructions expanding:
1. On R6 these instruction pack immediate offset into a 9-bit field. Now
if an immediate exceeds 9-bits assembler does not perform expansion and
just rejects such instruction.
2. On 64-bit non-PIC code if an operand is a symbol assembler generates
incorrect sequence of instructions. It uses R_MIPS_HI16 and R_MIPS_LO16
relocations and skips R_MIPS_HIGHEST and R_MIPS_HIGHER ones.
To solve these problems this patch:
- Introduces `mem_simm9_exp` to mark 9-bit memory immediate operands
which require expansion. Probably later all `mem_simm9` operands will be
able to migrate on `mem_simm9_exp` and we rename it to `mem_simm9`.
- Adds new `OPERAND_MEM_SIMM9` operand type and assigns it to the
`mem_simm9_exp`. That allows to know operand size in the `processInstruction`
method and decide whether we need to expand instruction.
- Adds `expandMem9Inst` method to expand instructions with 9-bit memory
immediate operand. This method just load immediate into a "base"
register used by origibal instruction:
sc $2, 256($sp) => addiu $1, $sp, 256
sc $2, 0($1)
- Fix `expandMem16Inst` to support a correct set of relocations for
symbol loading in case of 64-bit non-PIC code.
ll $12, symbol => lui $12, 0
R_MIPS_HIGHEST symbol
daddiu $12, $12, 0
R_MIPS_HIGHER symbol
dsll $12, $12, 16
daddiu $12, $12, 0
R_MIPS_HI16 symbol
dsll $12, $12, 16
ll $12, 0($12)
R_MIPS_LO16 symbol
- Fix `expandMem16Inst` to unify handling of 3 and 4 operands
instructions.
- Delete unused now `MipsTargetStreamer::emitSCWithSymOffset` method.
Task for next patches - implement expanding for other instructions use
`mem_simm9` operand and other `mem_simm##` operands.
Differential Revision: https://reviews.llvm.org/D70648
This has been factored out of D70654 which will add strict FP support to these functions. By making the helpers we avoid repeating even more code.
Differential Revision: https://reviews.llvm.org/D70736
Summary:
The Python ctypes FFI interface is broken on AIX, it cannot properly pass
structures containing arrays ( https://bugs.python.org/issue38628). So
disable the clang python binding tests on AIX till this is resolved.
Reviewers: stevewan, jasonliu, hubert.reinterpretcast, mgorny
Reviewed By: jasonliu, hubert.reinterpretcast
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70675
Sanjay Patel