to create a JIT. This lets you specify JIT-specific configuration items
like the JITMemoryManager to use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44647 91177308-0d34-0410-b5e6-96231b3b80d8
This allows an important optimization to be re-enabled.
- If all uses / defs of a split interval can be folded, give the interval a
low spill weight so it would not be picked in case spilling is needed (avoid
pushing other intervals in the same BB to be spilled).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44601 91177308-0d34-0410-b5e6-96231b3b80d8
throw exceptions", just mark intrinsics with the nounwind
attribute. Likewise, mark intrinsics as readnone/readonly
and get rid of special aliasing logic (which didn't use
anything more than this anyway).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44544 91177308-0d34-0410-b5e6-96231b3b80d8
into alias analysis. This meant updating the API
which now has versions of the getModRefBehavior,
doesNotAccessMemory and onlyReadsMemory methods
which take a callsite parameter. These should be
used unless the callsite is not known, since in
general they can do a better job than the versions
that take a function. Also, users should no longer
call the version of getModRefBehavior that takes
both a function and a callsite. To reduce the
chance of misuse it is now protected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44487 91177308-0d34-0410-b5e6-96231b3b80d8
attributes. While there, I noticed that not all
attribute methods returned a pointer-to-constant,
so I fixed that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44457 91177308-0d34-0410-b5e6-96231b3b80d8
in the middle of a split basic block, create a new live interval starting at
the def. This avoid artifically extending the live interval over a number of
cycles where it is dead. e.g.
bb1:
= vr1204 (use / kill) <= new interval starts and ends here.
...
...
vr1204 = (new def) <= start a new interval here.
= vr1204 (use)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44436 91177308-0d34-0410-b5e6-96231b3b80d8
the function type, instead they belong to functions
and function calls. This is an updated and slightly
corrected version of Reid Spencer's original patch.
The only known problem is that auto-upgrading of
bitcode files doesn't seem to work properly (see
test/Bitcode/AutoUpgradeIntrinsics.ll). Hopefully
a bitcode guru (who might that be? :) ) will fix it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44359 91177308-0d34-0410-b5e6-96231b3b80d8
trivial difference in function attributes, allow calls to it to
be converted to direct calls. Based on a patch by Török Edwin.
While there, move the various lists of mutually incompatible
parameters etc out of the verifier and into ParameterAttributes.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44315 91177308-0d34-0410-b5e6-96231b3b80d8
1) Change the interface to TargetLowering::ExpandOperationResult to
take and return entire NODES that need a result expanded, not just
the value. This allows us to handle things like READCYCLECOUNTER,
which returns two values.
2) Implement (extremely limited) support in LegalizeDAG::ExpandOp for MERGE_VALUES.
3) Reimplement custom lowering in LegalizeDAGTypes in terms of the new
ExpandOperationResult. This makes the result simpler and fully
general.
4) Implement (fully general) expand support for MERGE_VALUES in LegalizeDAGTypes.
5) Implement ExpandOperationResult support for ARM f64->i64 bitconvert and ARM
i64 shifts, allowing them to work with LegalizeDAGTypes.
6) Implement ExpandOperationResult support for X86 READCYCLECOUNTER and FP_TO_SINT,
allowing them to work with LegalizeDAGTypes.
LegalizeDAGTypes now passes several more X86 codegen tests when enabled and when
type legalization in LegalizeDAG is ifdef'd out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44300 91177308-0d34-0410-b5e6-96231b3b80d8
http://llvm.org/viewvc/llvm-project?rev=44199&view=rev
This patch completely broke serialization due to an invariant I assumed but
did not hold. The assumed invariant was that all pointer IDs emitted by a call
to BatchEmitOwnedPtrs would be consecutive. This is only the case if there has
been no forward references to an owned pointer (and hence already registered
with the Serializer object).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44203 91177308-0d34-0410-b5e6-96231b3b80d8