GNU as and Darwin give the various binary operators different
precedence. LLVM's MC supported the Darwin semantics but not the GNU
semantics.
This fixes PR25311.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251271 91177308-0d34-0410-b5e6-96231b3b80d8
We didn't validate that the .word directive was given a sane value,
leading to crashes when we attempt to write out the object file.
Instead, perform some validation and issue a diagnostic pointing at the
start of the diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251270 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of playing around with dominance to verify if the possible expansion of
a scop region is indeed a single entry single exit region, we now distinguish
two cases. In case we only append a basic block, all edges entering this basic
block need to have come from within the region that is expanded. In case we join
two regions, the source basic blocks of the edges that end at the entry node of
the region that is appended most be part of either the original region or the
region that is appended.
This change will be tested through Polly.
This fixes llvm.org/PR25242
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251267 91177308-0d34-0410-b5e6-96231b3b80d8
Windows has two different mangling specifiers. `x` is used on x86 for the `_`
UserLabelPrefix. Others use `w` for the no UserLabelPrefix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251260 91177308-0d34-0410-b5e6-96231b3b80d8
When the target does not support these intrinsics they should be converted to a chain of scalar load or store operations.
If the mask is not constant, the scalarizer will build a chain of conditional basic blocks.
I added isLegalMaskedGather() isLegalMaskedScatter() APIs.
Differential Revision: http://reviews.llvm.org/D13722
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251237 91177308-0d34-0410-b5e6-96231b3b80d8
When using the MCU psABI, compiler-generated library calls should pass
some parameters in-register. However, since inreg marking for x86 is currently
done by the front end, it will not be applied to backend-generated calls.
This is a workaround for PR3997, which describes a similar issue for -mregparm.
Differential Revision: http://reviews.llvm.org/D13977
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251223 91177308-0d34-0410-b5e6-96231b3b80d8
Most 128-bit and 256-bit shuffles were manually matching UNPCK patterns - use lowerVectorShuffleWithUNPCK to be more thorough.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251211 91177308-0d34-0410-b5e6-96231b3b80d8
I think it's fine to keep this fields around in terms of overhead,
I wasn't able to measure any substantial regression while running the
test suite, but, in case this causes some regression I'm ready to revert
and work on an alternative solution.
This was tested building with clang/gcc both in Debug and Release mode
and passes the test-suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251209 91177308-0d34-0410-b5e6-96231b3b80d8
This list is produced by llvm-config --system-libs to be used
by external programs using the llvm libraries, such as creduce.
In r250501 llvm/Support/Windows/Path.inc started to use the constant
FOLDERID_Profile from libuuid.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251201 91177308-0d34-0410-b5e6-96231b3b80d8
We don't need a mask of a rotation result to be a constant splat - any constant scalar/vector can be usefully folded.
Followup to D13851.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251197 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for lowering to the XOP VPROT / VPROTI vector bit rotation instructions.
This has required changes to the DAGCombiner rotation pattern matching to support vector types - so far I've only changed it to support splat vectors, but generalising this further is feasible in the future.
Differential Revision: http://reviews.llvm.org/D13851
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251188 91177308-0d34-0410-b5e6-96231b3b80d8
The loop idiom creating a ConstantRange is repeated twice in the
codebase, time to give it a name and a home.
The loop is also repeated in `rangeMetadataExcludesValue`, but using
`getConstantRangeFromMetadata` there would not be an NFC -- the range
returned by `getConstantRangeFromMetadata` may contain a value that none
of the subranges did.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251180 91177308-0d34-0410-b5e6-96231b3b80d8
