...and mark it as merely an input_iterator rather than a forward_iterator,
since it is destructive. And then rewrite == to take advantage of that.
Patch by Alex Denisov!
llvm-svn: 256913
If we replace one call-site with another, be sure to move over any
operand bundles that lingered on the old call-site.
This fixes PR26036.
llvm-svn: 256912
In the discussion on http://reviews.llvm.org/D15730, Andy pointed out we had a utility function for merging MMO lists. Since it turned we actually had two copies and there's another review in progress (http://reviews.llvm.org/D15230) which needs the same, extract it into a utility function and clean up the interfaces to make it easier to use with a MachineInstBuilder.
I introduced a pair here to track size and allocation together. I think we should probably move in the direction of the MachineOperandsRef helper class, but I'm leaving that for further work. I want to get the poison state introduced before I make major changes to the interface.
Differential Revision: http://reviews.llvm.org/D15757
llvm-svn: 256909
Summary:
Hi Rafael,
Would you be able to review this patch, please?
(Clang part of the patch is D15832).
When clang runs an external tool, e.g. a linker, it may create a command line that exceeds the length limit.
Clang uses the llvm::sys::argumentsFitWithinSystemLimits function to check if command line length fits the OS
limitation. There are two problems in this function that may cause exceeding of the limit:
1. It ignores the length of the program path in its calculations. On the other hand, clang adds the program
path to the command line when it runs the program.
2. It assumes no space character is inserted after the last argument, which is not true for Windows. The flattenArgs function adds the trailing space for *each* argument. The result of this is that the terminating NULL character is not counted and may be placed beyond the length limit if the command line is exactly 32768 characters long. The WinAPI's CreateProcess does not find the NULL character and fails.
Reviewers: rafael, ygao, probinson
Subscribers: asl, llvm-commits
Differential Revision: http://reviews.llvm.org/D15831
llvm-svn: 256866
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
llvm-svn: 256823
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.
Reviewers: sanjoy, reames
Subscribers: reames, sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D15762
llvm-svn: 256811
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.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15846
llvm-svn: 256809
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.
Patch by Justin Lebar!
llvm-svn: 256789
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.
Differential Revision: http://reviews.llvm.org/D15820
llvm-svn: 256787
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.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
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.
llvm-svn: 256730
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.
This fixes PR26000.
llvm-svn: 256728
Summary:
There are a number of files in the tree which have been accidentally checked in with DOS line endings. Convert these to native line endings.
There are also a few files which have DOS line endings on purpose, and I have set the svn:eol-style property to 'CRLF' on those.
Reviewers: joerg, aaron.ballman
Subscribers: aaron.ballman, sanjoy, dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D15848
llvm-svn: 256707
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.
llvm-svn: 256685
This restores the previous behavior of not including the mnemonic in the classes table for every target that starts instruction lines with the mnemonic. Not only did the table size increase by 1 entry, but the class enum increased in size which caused every class in the array to increase in size. It also grew the size of the function that parsers tokens into classes by a substantial amount.
This adds a new HasMnemonicFirst flag to all AsmParsers. It's set to 1 by default and Hexagon target overrides it to 0.
For the X86 target alone this recovers 324KB of size on the llvm-mc executable.
I believe the current state is still a bad design choice for the Hexagon target as it causes most of the parsing to do a linear search through the entire match table to comparing operands against every instruction until it finds one that works. At least for the other targets we do a binary search based on mnemonic over which to do the linear scan.
llvm-svn: 256669
This is part of the effort/prepration to reduce the size
instr-pgo (object, binary, memory footprint, and raw data).
The functionality is currently off by default and not yet
used by any clients.
llvm-svn: 256667
This reverts commit r256642 and restores r256620 now that Tobias has
updated Polly.
There are still some potential problems with the code in Polly that I've
sent post-commit review about, but they're unlikely to break anything in
practice, and I'd like to avoid the rest of LLVM and Clang regressing
here.
llvm-svn: 256656
As suggested in review for r255909, rename MDMaterialized to AllowTemps,
and identify the name of the boolean flag being set in calls to
saveMetadataList.
llvm-svn: 256653
As suggested in review for r255909, add a way to ensure that temporary
MD used as keys in the MetadataToID map during ThinLTO importing are not
RAUWed.
Add support for marking an MDNode as not replaceable. Clear the new
CanReplace flag when adding a temporary MD node to the MetadataToID map
and clear it when destroying the map.
llvm-svn: 256648
The commit we revert is rather small, but it enables a larger piece of new
infrastructure that allows to detected misuses of pointer-traits at compile
time. Unfortunately, this change breaks with the use of incomplete types (e.g.
in Polly). As I am not aware of a simple fix on the Polly side, I temporarely
revert this commit to clean the bots and sync-up with Chandler how to best
adapt to these recent changes.
This reverts commit https://llvm.org/svn/llvm-project/llvm/trunk@256620.
llvm-svn: 256642
alignment of the pointee type!
This is the culmination of the ptr-traits work. Now the compiler will
catch me if I try to use a pointer to an empty struct as a key in
a dense map or inside a PointerIntPair or PointerUnion! This is much,
much better than sometimes corrupting data (and other times working
fine) due to insufficient alignment.
It also means that we will be much more diligent about rejecting other
uses of these constructs that aren't safe.
It also means that we can now be more aggressive with the constructs
when we actually have guaranteed higher alignment without specializing
stuff. I'll be going through and cleaning up all the current overrides
of these traits which are no longer necessary.
Many thanks to Richard, David, and others who helped me get all of this
together.
llvm-svn: 256620
to isolate it in a dependent helper class.
Without doing this, we end up requiring all of the pointer traits the
moment you even define a PointerIntPair. That makes them *incredibly*
hard to use, for example you can't use them at all inside a class for
pointers to that class!
This change sinks all the logic into a helper template class that only
needs to be fully instantiated when *using* the PointerIntPair. We still
get compile-time checking, but it is deferred long enough to make
tradition out-of-line method definitions (or just the normal deferred
method body parsing) sufficient to handle cycling references.
llvm-svn: 256618
This is necessary to use them as part of pointer traits and is generally
useful. I've added unit test coverage to isolate and ensure this works
correctly.
I'll watch the build bots to try to see if any compilers can't tolerate
this bit of magic (and much credit goes to Richard Smith for coming up
with this magical production!) but give a shout if you see issues.
llvm-svn: 256553
inline definitions after the mutually recursive pair of types have been
defined. The two types mutually recurse specifically through
abstractions that require pointer traits which makes this kind of mutual
recursion especially tricky to get right in terms of ordering.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
llvm-svn: 256551
missing includes so that the pointee types for DenseMap pointer keys and
such are complete prior to us querying the pointer traits for them.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
llvm-svn: 256550
used in pointer dense map key types or in other ways that require
pointer traits.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
llvm-svn: 256549
header to its own header, allowing users of fragments to have a narrower
header file, and avoid circular header dependencies when getting the
definition of MCSection prior to inspecting traits on MCSection
pointers.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
Note that this doesn't in any way change the design of MC, it is just
moving code around to allow the *header files* to be more fine grained.
Without this, it is impossible to get a complete type for MCSection
where it is needed.
If anyone would prefer a different slicing of the header files, I'm
happy to oblige of course. =]
llvm-svn: 256548
