Summary:
Refactor loop peeling code by moving code for calculating phi invariance
into a separate class that does the calculation. Redescribe and rework
the algorithm in preparation for adding increased functionality. Add
test case that does not exhibit peeling that will be subsequently supported.
Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By: mkazantsev (Max Kazantsev)
Differential Revision: https://reviews.llvm.org/D138232
The unused variable fix also remove the test output of the tokens
that do not match, making debugging tests harder. Undo the semantic
changes of the build fix.
This patch relaxes the verifier for the fir.rebox operation
to allow reboxing to unlimited polymoprhic box.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D138695
Use the same register layout as Linux kernel, implement the
related read and write operations.
Reviewed By: SixWeining, xen0n, DavidSpickett
Differential Revision: https://reviews.llvm.org/D138407
This change is focussed on simplifying `Support/Host.h` to only do
target detection. In this case, this function is close in usage to
existing functions in `Support/Threading.h`, so I moved it into there.
The function is also renamed to `llvm::get_physical_cores()` to match
the style of threading's functions.
Differential Revision: https://reviews.llvm.org/D137836
The dynamic type of an unlimited polymorphic entity has the
derived category but does not have derived type spec. This leads
to a crash for a nullptr dereference. This patch avoids this crash
by checking if that the dynamic type is not unlimited polymorphic
before dereferencing the derived type spec.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D138691
This patch reduces the number of unpredictable branches
(select (x < 0), y, z) -> x >> (XLEN - 1) & (y - z) + z
(select (x >= 0), y, z) -> x >> (XLEN - 1) & (z - y) + y
Reviewed By: craig.topper, reames
Differential Revision: https://reviews.llvm.org/D137949
Targets and Refs are 1:1, so merge them.
Don't sort Refs array we keep indices into. (Currently we're done using
those indices by the time we sort, but this is fragile)
This used to be required, but the difference between asserts/!asserts
builds no longer exists for %clang_cc1 (only for %clang), so they pass
just fine without this flag.
Use a dyn_cast<> to IntrinsicInst and an enum compare instead.
While touching this code also re-generate the test to use positive check
lines instead of negative ones and remove some unneeded metadata.
Reviewed By: yonghong-song
Differential Revision: https://reviews.llvm.org/D138565
If one of the AND operands is a setcc then we're implicitly zeroing the upper mask bits
Similar pattern to regressions identified in D127115 (masked comparisons)
Demo: 7911d8251c/PathMapping.cpp.html
Header insertion doesn't actually work that well (not this patch's fault):
- we don't have ranking of locations/headers yet, so inserted header is pretty
random
- on my system, we get a lot of absolute "/usr/bin/../include/..." paths.
This is a HeaderSearch bug introduced in D60873 that I'll send a fix for
Differential Revision: https://reviews.llvm.org/D138676
A malformed qMemoryRegionInfo response can easily trigger an infinite
loop if regions end (base + size) wraps the address space. A
particularly interesting is the case where base+size=0, which a stub
could use to say that the rest of the memory space is unmapped, even
though lldb expects 0xff... in this case.
One could argue which behavior is more correct (technically, the
current behavior does not say anything about the last byte), but unless
we stop using 0xff... to mean "invalid address", that discussion is very
academic. This patch truncates address ranges which wraps the address
space, which handles the zero case as well as other kinds of malformed
packets.
This allows DemandedBits to see that the SVE count intrinsics (CNTB,
CNTH, CNTW, CNTD) sans multiplier will only ever produce small
positive integers. The maximum value you could get here is 256, which
is CNTB on a machine with a 2048bit vector size (the maximum for SVE).
Using this various redundant operations (zexts, sexts, ands, ors, etc)
can be eliminated.
Differential Revision: https://reviews.llvm.org/D138424
Since D60873 we remove dotdots from the search path entries, but not the
filenames we're matching against, so do the latter too.
Since this also removes (single) dots, drop the logic to skip over them.
(Some of this was already dead, some is newly dead).
See D138676 for motivation.
Differential Revision: https://reviews.llvm.org/D138677
By default, clang assumes that all trailing array objects could be a
FAM. So, an array of undefined size, size 0, size 1, or even size 42 is
considered as FAMs for optimizations at least.
One needs to override the default behavior by supplying the
`-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of
FAM candidates. Value `3` is the most restrictive and `0` is the most
permissive on this scale.
0: all trailing arrays are FAMs
1: only incomplete, zero and one-element arrays are FAMs
2: only incomplete, zero-element arrays are FAMs
3: only incomplete arrays are FAMs
If the user is happy with consdering single-element arrays as FAMs, they
just need to remove the
`consider-single-element-arrays-as-flexible-array-members` from the
command line.
Otherwise, if they don't want to recognize such cases as FAMs, they
should specify `-fstrict-flex-arrays` anyway, which will be picked up by
CSA.
Any use of the deprecated analyzer-config value will trigger a warning
explaining what to use instead.
The `-analyzer-config-help` is updated accordingly.
Depends on D138657
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D138659
According to my measurement in https://reviews.llvm.org/D108230#3933232,
it seems like there is no drawback to enabling this analyzer-config by default.
Actually, enabling this by default would make it consistent with the
codegen of clang, which according to `-fstrict-flex-arrays`, assumes
by default that all trailing arrays could be FAMs, let them be of size
undefined, zero, one, or anything else.
Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate
the analyzer-config FAM option in favor of that flag. That way, CSA will
always be in sync with what the codegen will think of FAMs.
So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0,
CSA will also make sure that only arrays of the right size will be
considered as FAMs.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D138657
This flag should be used for instructions which create constant values.
So, remove the flag from not proper instructions. Only LEA, LEASL, and
OR instructions have the flag now.
Reviewed By: efocht
Differential Revision: https://reviews.llvm.org/D138544
hlfir.concat codegen happens in the "bufferization" pass: the pass
that place hlfir.expr in memory and transform all operations producing
or accepting hlfir.expr arguments into operations operating on memory.
Since this pass gets rid of the hlfir.expr type, this is a full
translation pass.
So far hlfir.concat codegen re-uses the current concatenation lowering helper
and only supports concatenation of two strings at a time. This matches
what lowering to HLFIR without any optimization produces. More optimized
versions will be developed later.
Differential Revision: https://reviews.llvm.org/D138673
When a module contains more than one function, we should update debugify metadata
by increasing the number of variables in the function rather than overwritting it.
Previous revert issue is fixed: I forgot to strip all x86-related info from the
test.
Differential Revision: https://reviews.llvm.org/D136949
Incorrect `isOverriding` flag triggers the assertion
`!Overridden.empty()` in `ObjCMethodDecl::getOverriddenMethods` when a
method is marked as overriding but we cannot find any overrides.
When a method is declared in a category and defined in implementation,
we don't treat it as an override because it is the same method with
a separate declaration and a definition. But with modules we can find
a method declaration both in a modular category and a non-modular category
with different memory addresses. Thus we erroneously conclude the method
is overriding. Fix by comparing canonical declarations that are the same
for equal entities coming from different modules.
rdar://92845511
Differential Revision: https://reviews.llvm.org/D138630
When building for Windows aarch64, and not using the actual MSVC,
we can assemble gnu assembly files just fine, and the existing
correct implementation of __kmp_invoke_microtask is fully usable.
The C implementation of __kmp_invoke_microtask in
z_Windows_NT-586_util.cpp relies on unguaranteed assumptions about
the compiler behaviour - it does work currently on MSVC, but doesn't
necessarily on other compilers. That function uses an alloca to pass
parameters on the stack to the called functions.
There's no guarantee that the buffer allocated by alloca is exactly
at the bottom of the stack when doing the call; the compiler might
have left space for extra things to save on the stack there.
Additionally, when compiled with Clang with optimization, Clang
optimizes out the alloca and memcpy entirely. On the C language
level, they don't have any visible effect outside of the function
and thus can be omitted entirely.
This fixes calling microtasks with more than 6 parameters, in
builds for Windows/aarch64 with Clang.
Differential Revision: https://reviews.llvm.org/D137827
Jamie Schmeiser