This revealed that scalar intrinsics could create nodes with a rounding mode of FROUND_CUR_DIRECTION, but the patterns didn't check for it. It just worked because isel doesn't check operand count and we had a pattern without the rounding mode argument at all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282231 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
For AMDGPU, we have been using the operating system component of the triple
for specifying the low-level runtime that is being used. The rationale for
this is that the host operating system (e.g. Linux) is irrelevant for GPU code,
since its execution enviroment will be mostly controled by the low-level runtime
being used to execute the code.
In most cases, higher level languages have their own runtime which is
implemented on top of the low-level runtime. The kernel ABIs of each
language mostly depend on the low-level runtime, but there may be some
slight differences between languages. OpenCL for example, may append
additional arguments to the kernel in order to pass values like global
offsets or buffers for printf. OpenMP, HCC, or other languages may want
to add their own values which differ from OpenCL.
The reason for adding a new opencl environment type is to make it possible for the backend
to distinguish between the ABIs of the higher-level languages and handle them correctly.
It seems cleaner to use the enviroment component for this rather than creating a new
OS type for every combination of low-level runtime / high-level language.
Reviewers: Anastasia, chandlerc
Subscribers: whchung, pekka.jaaskelainen, wdng, yaxunl, llvm-commits
Differential Revision: https://reviews.llvm.org/D24735
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282218 91177308-0d34-0410-b5e6-96231b3b80d8
Statically instanciate the most common PartialMappings. This should
be closer to what the code would look like when TableGen support is
added for GlobalISel. As a side effect, this should improve compile
time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282215 91177308-0d34-0410-b5e6-96231b3b80d8
In the verify method of the ValueMapping class we used to check that the
mapping exactly matches the bits of the input value. This is problematic
for statically allocated mappings because we would need a different
mapping for each different size of the value that maps on one
instruction. For instance, with such scheme, we would need a different
mapping for a value of size 1, 5, 23 whereas they all end up on a 32-bit
wide instruction.
Therefore, change the verifier to check that the meaningful bits are
covered by the mapping instead of matching them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282214 91177308-0d34-0410-b5e6-96231b3b80d8
This is another step toward TableGen'ed like structures. The BreakDown of
the mapping of the value will be statically computed by TableGen, thus
we only have to point to the right entry in the table instead of
dynamically allocate the mapping for each instruction.
We still support the dynamic allocation through a factory of
PartialMapping to ease the bring-up of the targets while the TableGen
backend is not available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282213 91177308-0d34-0410-b5e6-96231b3b80d8
Add two options to the code coverage artifact prep script:
* --use-existing-profdata: Use an existing indexed profile instead of
merging the same profiles again.
* --restrict: Restrict the coverage reporting to the given list of
source directories.
With this in place, we can teach the coverage bot how to prepare
separate reports for each of the llvm tools.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282204 91177308-0d34-0410-b5e6-96231b3b80d8
We've supported restricting coverage reports to a set of files for a
long time. Add support for being able to restrict by entire directories.
I suppose this supersedes D20803.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282202 91177308-0d34-0410-b5e6-96231b3b80d8
Currently all nodes get added to the NextSU list when they are released,
so any candidate must be in that list, making the heuristic ineffective.
Remove it for now, we can add it back later in a working fashion if
necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282200 91177308-0d34-0410-b5e6-96231b3b80d8
and also the dependent r282175 "GVN-hoist: do not dereference null pointers"
It's causing compiler crashes building Harfbuzz (PR30499).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282199 91177308-0d34-0410-b5e6-96231b3b80d8
USR_OVF is a subregister of USR, which is a member of CtrRegs. Having both
a register and its proper subregister in the same register class has bad
consequences for lane mask calculation: based solely on the lane mask info,
USR_OVF would not appear to be a subregister of USR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282192 91177308-0d34-0410-b5e6-96231b3b80d8
According to MSDN (see the PR), functions which don't touch any callee-saved
registers (including %rsp) don't need any unwind info.
This patch makes LLVM not emit unwind info for such functions, to save
binary size.
Differential Revision: https://reviews.llvm.org/D24748
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282185 91177308-0d34-0410-b5e6-96231b3b80d8
Atomic comparison instructions use the sub-word load instruction on
Power8 and up but the value is not sign extended prior to the signed word
compare instruction. This patch adds that sign extension.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282182 91177308-0d34-0410-b5e6-96231b3b80d8
there may be basic blocks without memory accesses, in which case the
list of accesses is a null pointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282175 91177308-0d34-0410-b5e6-96231b3b80d8
A recent patch added support for consumeInteger() and made
getAsInteger delegate to this function. A few buildbots are
failing as a result with an assertion failure. On a hunch,
I tested what happens if I call getAsInteger() on an empty
string, and sure enough it crashes the same way that the
buildbots are crashing.
I confirmed that getAsInteger() on an empty string did not
crash before my patch, so I suspect this to be the cause.
I also added a unit test for the empty string.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282170 91177308-0d34-0410-b5e6-96231b3b80d8
To hoist stores past loads, we used to search for potential
conflicting loads on the hoisting path by following a MemorySSA
def-def link from the store to be hoisted to the previous
defining memory access, and from there we followed the def-use
chains to all the uses that occur on the hoisting path. The
problem is that the def-def link may point to a store that does
not alias with the store to be hoisted, and so the loads that are
walked may not alias with the store to be hoisted, and even as in
the testcase of PR30216, the loads that may alias with the store
to be hoisted are not visited.
The current patch visits all loads on the path from the store to
be hoisted to the hoisting position and uses the alias analysis
to ask whether the store may alias the load. I was not able to
use the MemorySSA functionality to ask for whether load and
store are clobbered: I'm not sure which function to call, so I
used a call to AA->isNoAlias().
Store past store is still working as before using a MemorySSA
query: I added an extra test to pr30216.ll to make sure store
past store does not regress.
Differential Revision: https://reviews.llvm.org/D24517
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282168 91177308-0d34-0410-b5e6-96231b3b80d8
StringRef::getInteger() exists and treats the entire string as
an integer of the specified radix, failing if any invalid characters
are encountered or the number overflows.
Sometimes you might have something like "123456foo" and you want
to get the number 123456 and leave the string "foo" remaining.
This is similar to what would be possible by using the standard
runtime library functions strtoul et al and specifying an end
pointer.
This patch adds consumeInteger(), which does exactly that. It
consumes as much as possible until an invalid character is found,
and modifies the StringRef in place so that upon return only
the portion of the StringRef after the number remains.
Differential Revision: https://reviews.llvm.org/D24778
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282164 91177308-0d34-0410-b5e6-96231b3b80d8
Without this patch, GVN-hoist would think that a branch instruction is a scalar instruction
and would try to value number it. The patch filters out all such kind of irrelevant instructions.
A bit frustrating is that there is no easy way to discard all those very infrequent instructions,
a bit like isa<TerminatorInst> that stands for a large family of instructions. I'm thinking that
checking for those very infrequent other instructions would cost us more in compilation time
than just letting those instructions getting numbered, so I'm still thinking that a simpler check:
if (isa<TerminatorInst>(I))
return false;
is better than listing all the other less frequent instructions.
Differential Revision: https://reviews.llvm.org/D23929
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282160 91177308-0d34-0410-b5e6-96231b3b80d8
The additional fix is:
When adding debug information to a lowered phi node in mem2reg
check that we have a valid insertion point after the phi for adding
the debug information.
This change addresses the issue in pr30468 where a lowered phi was
added before a catchswitch and no debug information should be added
after the phi in this case.
Differential Revision: https://reviews.llvm.org/D24797
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282155 91177308-0d34-0410-b5e6-96231b3b80d8
This patch corresponds to:
https://reviews.llvm.org/D21409
The LXVD2X, LXVW4X, STXVD2X and STXVW4X instructions permute the two doublewords
in the vector register when in little-endian mode. Custom code ensures that the
necessary swaps are inserted for these. This patch simply removes the possibilty
that a load/store node will match one of these instructions in the SDAG as that
would not insert the necessary swaps.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282144 91177308-0d34-0410-b5e6-96231b3b80d8
This patch corresponds to review:
https://reviews.llvm.org/D19825
The new lxvx/stxvx instructions do not require the swaps to line the elements
up correctly. In order to select them over the lxvd2x/lxvw4x instructions which
require swaps, the patterns for the old instruction have a predicate that
ensures they won't be selected on Power9 and newer CPUs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282143 91177308-0d34-0410-b5e6-96231b3b80d8
