David Majnemer [Tue, 5 Jan 2016 17:46:36 +0000 (17:46 +0000)]
[X86] Determine if we have an OpaqueSPAdjustment earlier
We queried hasFP before we hit ExpandISelPseudos. ExpandISelPseudos
manipulated state that hasFP relied on, potentially changing the result
after it has been queried elsewhere.
While I am not aware of any particular bug due to this state of affairs,
it seems best to avoid it entirely by changing the state during DAG
construction.
Aaron Ballman [Tue, 5 Jan 2016 14:24:01 +0000 (14:24 +0000)]
Enable more strict standards conformance in MSVC for rvalue casting and string literal type conversion to non-const types. Also enables generation of intrinsics for more functions.
Artyom Skrobov [Tue, 5 Jan 2016 10:25:56 +0000 (10:25 +0000)]
(NFC) Change SubtargetFeatures::ToggleFeature and
SubtargetFeatures::ApplyFeatureFlag to be static, so that
MCSubtargetInfo doesn't need to instantiate SubtargetFeatures
for nothing. Also change the return type to void, as it
wasn't ever used.
This is a partial commit of http://reviews.llvm.org/D15746
Simon Pilgrim [Tue, 5 Jan 2016 09:12:17 +0000 (09:12 +0000)]
[X86][SSE] Merge PerformBLENDICombine into PerformShuffleCombine
PBLEND/BLENDPD/BLENDPS are no different to the other target shuffles and this will make future improvements to the target shuffle combines more straightforward.
David Majnemer [Tue, 5 Jan 2016 07:42:17 +0000 (07:42 +0000)]
[SimplifyCFG] Further improve our ability to remove redundant catchpads
In r256814, we managed to remove catchpads which were trivially redudant
because they were the same SSA value. We can do better using the same
algorithm but with a smarter datastructure by hashing the SSA values
within the catchpad and comparing them structurally.
Manuel Jacob [Tue, 5 Jan 2016 04:06:21 +0000 (04:06 +0000)]
[RS4GC] Simplify handling of Constants in findBaseDefiningValue(). NFC.
Summary:
Previously there were three conditionals, checking for global
variables, undef values and everything constant except these two, all three
returning the same value. This commit replaces them by one conditional.
Manuel Jacob [Tue, 5 Jan 2016 04:03:00 +0000 (04:03 +0000)]
[Statepoints] Refactor GCRelocateOperands into an intrinsic wrapper. NFC.
Summary:
This commit renames GCRelocateOperands to GCRelocateInst and makes it an
intrinsic wrapper, similar to e.g. MemCpyInst. Also, all users of
GCRelocateOperands were changed to use the new intrinsic wrapper instead.
Summary:
At least for CoreCLR, a catchpad which immediately executes an
`unreachable` instruction indicates that the exception can never have a
matching type, and so such catchpads can be removed, and so can their
catchswitches if the catchswitch becomes empty.
David Majnemer [Tue, 5 Jan 2016 02:32:06 +0000 (02:32 +0000)]
Revert "[X86] Use push-pop for materializing small constants under 'minsize'"
The red zone consists of 128 bytes beyond the stack pointer so that the
allocation of objects in leaf functions doesn't require decrementing
rsp. In r255656, we introduced an optimization that would cheaply
materialize certain constants via push/pop. Push decrements the stack
pointer and stores it's result at what is now the top of the stack.
However, this means that using push/pop would encroach on the red zone.
PR26023 gives an example where this corrupts an object in the red zone.
Tom Stellard [Tue, 5 Jan 2016 02:26:37 +0000 (02:26 +0000)]
AMDGPU/SI: Consolidate FLAT patterns
Summary:
We had to sets of identical FLAT patterns one inside the
HasFlatAddressSpace predicate and one inside the useFlatForGloabl
predicate. This patch merges these sets into a single pattern
under the isCIVI predicate.
The reason we can remove the predicates is that when MUBUF instructions
are legal, the instruction selector will prefer selecting those over
FLAT instructions because MUBUF patterns have a higher complexity score.
So, in this case having patterns for FLAT instructions will have no effect.
This change also simplifies the process for forcing global address space
loads to use FLAT instructions, since we no only have to disable the
MUBUF patterns instead of having to disable the MUBUF patterns and
enable the FLAT patterns.
Philip Reames [Tue, 5 Jan 2016 00:49:14 +0000 (00:49 +0000)]
[MDA] Don't be quite as conservative for noalias functions
If we encounter a noalias call that alias analysis can't analyse, we can fall down into the generic call handling rather than giving up entirely. I noticed this while reading through the code for another purpose.
I can't seem to write a test case which changes; that sorta makes sense given any test case would have to be an inconsistency in AA. Suggestions welcome.
Unfortunately this fix had the effect of exposing the
-verify-machineinstrs FIXME of X86InstrInfo.cpp in two testcases for
which I disabled it for now.
Two testcases also have additional pushq/popq where the corrected code
cannot prove that %rax is dead any longer. Looking at the examples, this
could potentially be fixed by improving computeRegisterLiveness() to check
the live-in lists of the successors blocks when reaching the end of a
block.
Nicolai Haehnle [Mon, 4 Jan 2016 23:35:53 +0000 (23:35 +0000)]
AMDGPU: add +xnack feature
Summary:
Enabling this feature will account for the two SGPRs used by the hardware
to store the XNACK_MASK physically.
The hardware only requires this reservation when the XNACK feature is
explicitly enabled. At some point, HSA will probably want to do that, but
it does increase SGPR register pressure, so leave it disabled by default
for now (but do add a small test).
Chen Li [Mon, 4 Jan 2016 23:28:57 +0000 (23:28 +0000)]
[InstructionCombining] prepareICWorklistFromFunction halts in infinite loop with instructions of token type
Summary: This patch fixes a bug in prepareICWorklistFromFunction, where the loop becomes infinite with instructions of token type. The patch checks if the instruction is token type, and if so it updates EndInst with the current instruction.
CMake v3.2 or newer is necessary to get interactive output when running
Lit via Ninja. Otherwise Ninja will buffer Lit's output, which makes
for a crummy experience -- you can't tell if your tests are hung!
Clarify that the bypassSlowDivision optimization operates on a single BB [v2]
Update some comments to be more explicit.
Change bypassSlowDivision and the functions it calls so that they take
BasicBlock*s and Instruction*s, rather than Function::iterator&s and
BasicBlock::iterator&s.
Change the APIs so that the caller is responsible for updating the
iterator, rather than the callee. This makes control flow much easier
to follow.
David Majnemer [Mon, 4 Jan 2016 23:16:22 +0000 (23:16 +0000)]
[LICM] Fix a small oversight introduced in r256763
r256763 had promoteLoopAccessesToScalars check for the existence of a
catchswitch when the exit blocks were populated but
promoteLoopAccessesToScalars may be called with a prepopulated set of
exit blocks which would also need to be checked.
Philip Reames [Mon, 4 Jan 2016 22:49:23 +0000 (22:49 +0000)]
[MemoryBuiltins] Remove isOperatorNewLike by consolidating non-null inference handling
This patch removes the isOperatorNewLike predicate since it was only being used to establish a non-null return value and we have attributes specifically for that purpose with generic handling. To keep approximate the same behaviour for existing frontends, I added the various operator new like (i.e. instances of operator new) to InferFunctionAttrs. It's not really clear to me why this isn't handled in Clang, but I didn't want to break existing code and any subtle assumptions it might have.
Once this patch is in, I'm going to start separating the isAllocLike family of predicates. These appear to be being used for a mixture of things which should be more clearly separated and documented. Today, they're being used to indicate (at least) aliasing facts, CSE-ability, and default values from an allocation site.
Haicheng Wu [Mon, 4 Jan 2016 21:43:14 +0000 (21:43 +0000)]
[LIR] General refactoring to simplify code and the ease future code review
This is a resubmission of r256336 which was reverted in r256361. The issue was the lack of the invariant check of the memset value in processLooMemSet().
The original message:
Move several checks into isLegalStores. Also, delineate between those stores that are memset-able and those that are memcpy-able.
Before reevaluating instructions, iterate over all instructions
to be reevaluated and remove trivially dead instructions and if
any of it's operands become trivially dead, mark it for deletion
until all trivially dead instructions have been removed
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Nicolai Haehnle [Mon, 4 Jan 2016 15:50:01 +0000 (15:50 +0000)]
AMDGPU: Avoid assertions after SGPR spilling failed
Summary:
The comment explains it: emitError does not necessarily exit the compilation
process, and then using NoRegister leads to assertions later on.
This generates incorrect code, of course, but the user should know to not use
the result when an error has been emitted.
It would be nice to have a test-case for this inside the LLVM repository,
but llc exits on error. shader-db tests trigger the underlying issue at least
on Tonga.
Fix a horrible infloop in value tracking in the face of dead code.
Amazingly, we just never triggered this without:
1) Moving code around for MetadataTracking so that a certain *different*
amount of inlining occurs in the per-TU compile step.
2) Then you LTO opt or clang with a bootstrap, and get inlining, loop
opts, and GVN line up everything *just* right.
I don't really know how we didn't hit this before. We really need to be
fuzz testing stuff, it shouldn't be hard to trigger. I'm working on
crafting a reduced nice test case, and will submit that when I have it,
but I want to get LTO build bots going again.
David Majnemer [Mon, 4 Jan 2016 04:49:41 +0000 (04:49 +0000)]
[X86] Make hasFP constant time
We need a frame pointer if there is a push/pop sequence after the
prologue in order to unwind the stack. Scanning the instructions to
figure out if this happened made hasFP not constant-time which is a
violation of expectations. Let's compute this up-front and reuse that
computation when we need it.
David Majnemer [Mon, 4 Jan 2016 03:37:39 +0000 (03:37 +0000)]
[LICM] Make instruction sinking funclet-aware
We had two bugs here:
- We might try to sink into a catchswitch, causing verifier failures.
- We will succeed in sinking into a cleanuppad but we didn't update the
funclet operand bundle.
Craig Topper [Mon, 4 Jan 2016 03:15:08 +0000 (03:15 +0000)]
[TableGen] Change TGParser::SetValue to take an ArrayRef instead of std::vector reference. Use None in many places where a default constructed vector was being passed. NFC
Craig Topper [Mon, 4 Jan 2016 03:05:14 +0000 (03:05 +0000)]
[TableGen] Fix a bug that caused the wrong name for a record built from a multiclass containing a defm called NAME that references another multiclass that contains a defm that uses NAME concatenated with other strings.
It would end up doing the concatenations from the second multiclass twice. This occured because SetValue detected a self assignment when trying to set the value of NAME to a VarInit called NAME. NAME is special here and it will get cleaned up later. So add a flag to suppress the self assignment check for this case.
Strangely the self-assignment error was returning false indicating it wasn't an error, but it wasn't doing the right thing. So this also changes it to report an error.
This fixes the names of some AVX512 FMA instructions that showed this double expansion.
[PGO] Cleanup: Use covmap header definition in the template file
This is one last remaining instrumentatation related structure
that needs to be migrate to use the centralized template
definition. With this change, instrumentation code
related to coverage module header will be kept in sync
with the coverage mapping reader. The remaining code
which makes implicit assumption about covmap control
structure layout in the the lowering pass will cleaned
up in a different patch. This patch is not intended to
have no functional change.
Simon Pilgrim [Sun, 3 Jan 2016 18:24:19 +0000 (18:24 +0000)]
[SelectionDAG] Pulled out common code for CONCAT_VECTORS node creation
Pulled out the similar CONCAT_VECTORS creation code from the 2/3 operand getNode() calls (to handle all UNDEF and all BUILD_VECTOR cases). Added a similar handler to the general getNode() call as well.
Craig Topper [Sun, 3 Jan 2016 08:57:41 +0000 (08:57 +0000)]
[TableGen] Simplify some code slightly. No need to check if the arrays are empty before printing. The loop can be made to print the same thing if the loop is empty. NFC
Summary:
Add a pass to update catchrets when their successors get cloned; the
existing pass doesn't catch these because it walks the funclet whose
blocks are being cloned but the catchret is in a child funclet.
Also update the test for removing incoming PHI values; when the
predecessor is a catchret, the relevant color is the catchret's parentPad,
not its block's color.
Yaron Keren [Sat, 2 Jan 2016 13:40:36 +0000 (13:40 +0000)]
Correct misleading formatting of several ifs followed by two statements without braces.
While the original code would work with or without braces, it makes sense to
set HaveSemi to true only if (!HaveSemi), otherwise it's already true, so I
put the assignment inside the if block. This addresses PR25998.
David Majnemer [Sat, 2 Jan 2016 09:26:36 +0000 (09:26 +0000)]
[WinEH] Add additional verification
Recolor the IR to make sure our computed colors are not hiding any bugs.
Also, verifyFunction if we are running some post-preparation operations;
some of these operations can hide latent bugs.
David Majnemer [Fri, 1 Jan 2016 06:50:01 +0000 (06:50 +0000)]
[X86] Add intrinsics for reading and writing to the flags register
LLVM's targets need to know if stack pointer adjustments occur after the
prologue. This is needed to correctly determine if the red-zone is
appropriate to use or if a frame pointer is required.
Normally, LLVM can figure this out very precisely by reasoning about the
contents of the MachineFunction. There is an interesting corner case:
inline assembly.
The vast majority of inline assembly which will perform a push or pop is
done so to pair up with pushf or popf as appropriate. Unfortunately,
this inline assembly doesn't mark the stack pointer as clobbered
because, well, it isn't. The stack pointer is decremented and then
immediately incremented. Because of this, LLVM was changed in r256456
to conservatively assume that inline assembly contain a sequence of
stack operations. This is unfortunate because the vast majority of
inline assembly will not end up manipulating the stack pointer in any
way at all.
Instead, let's provide a more principled solution: an intrinsic.
FWIW, other compilers (MSVC and GCC among them) also provide this
functionality as an intrinsic.
projects / llvm / log