arrays. Also, as a convenience, don't barf, just
return false, if someone calls isTruncStoreLegal
or isLoadXLegal with an extended type for the in
memory type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46352 91177308-0d34-0410-b5e6-96231b3b80d8
APInt.
While some operators were already specifically overloaded for APSInt, others
resulted in using the overloaded operator methods in APInt, which would result
in the signedness bit being lost.
Modified the APSInt(APInt&) constructor to be "explicit" and to take an
extra (optional) flag to indicate the signedness. Making the ctor explicit
will catch any implicit conversations between APSInt -> APInt -> APSInt that
results in the signedness flag being lost.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46316 91177308-0d34-0410-b5e6-96231b3b80d8
getNodeLabel(); these sequences allow the user to specify the characters '{',
'}', and '|' in the label, which facilitate breaking the label into multiple
record segments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46283 91177308-0d34-0410-b5e6-96231b3b80d8
Made ImmutableSet::ImmutableSet(ImutAVLTree* Root) public. (this allows handy
casting between trees and sets).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46277 91177308-0d34-0410-b5e6-96231b3b80d8
problem was that we previously hashed based on the pointers of the left and
right children, but this is bogus: we can easily have different trees that
represent the same set. Now we use a hashing based scheme that compares the
*contents* of the trees, but not without having to do a full scan of a tree. The
only caveat is that with hashing is that we may have collisions, which result in
two different trees being falsely labeled as equivalent. If this becomes a
problem, we can add extra data to the profile to hopefully resolve most
collisions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46224 91177308-0d34-0410-b5e6-96231b3b80d8
'FoldingSetNodeImpl' (previously 'FoldingSetNodeID' was a typedef of
'FoldingSetNodeImpl::NodeID').
Why? Clients can now easily forward declare 'FoldingSetNodeID' without having
to include FoldingSet.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46187 91177308-0d34-0410-b5e6-96231b3b80d8
instead of always assuming that the stored objects had a method called
'Profile'. The default behavior is to dispatch to a 'Profile' method (as
before), but via template specialization this behavior can now be overridden by
clients.
Added templated class 'FoldingSetNodeWrapper', a generic wrapper class that
allows one to insert objects into a FoldingSet that do not directly inherit from
FoldingSetNode. This is useful for inserting objects that do not always need to
pay the overhead of inheriting from FoldingSetNode, or were designed with that
behavior in mind.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46186 91177308-0d34-0410-b5e6-96231b3b80d8
an iterator, since the implementation returned an iterator that pointed to a
different node! Renamed this implementation to SlimFind() so that users do not
expect it to return an iterator (it is a more efficient implementation than
returning an iterator if the user just wants to find the value of a key).
Added a FIXME to implement ImmutableMap::find() that returns an iterator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46150 91177308-0d34-0410-b5e6-96231b3b80d8
1. Legalize now always promotes truncstore of i1 to i8.
2. Remove patterns and gunk related to truncstore i1 from targets.
3. Rename the StoreXAction stuff to TruncStoreAction in TLI.
4. Make the TLI TruncStoreAction table a 2d table to handle from/to conversions.
5. Mark a wide variety of invalid truncstores as such in various targets, e.g.
X86 currently doesn't support truncstore of any of its integer types.
6. Add legalize support for truncstores with invalid value input types.
7. Add a dag combine transform to turn store(truncate) into truncstore when
safe.
The later allows us to compile CodeGen/X86/storetrunc-fp.ll to:
_foo:
fldt 20(%esp)
fldt 4(%esp)
faddp %st(1)
movl 36(%esp), %eax
fstps (%eax)
ret
instead of:
_foo:
subl $4, %esp
fldt 24(%esp)
fldt 8(%esp)
faddp %st(1)
fstps (%esp)
movl 40(%esp), %eax
movss (%esp), %xmm0
movss %xmm0, (%eax)
addl $4, %esp
ret
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46140 91177308-0d34-0410-b5e6-96231b3b80d8
and not just the key value when comparing trees. To do this we added data_type
and data_type_ref to the ImutContainerInfo trait classes. For values stored in
the tree that do not have separate key and data components, data_type is simply
a typedef of bool, and isDataEqual() always evaluates to true. This allows us to
support both ImmutableSet and ImmutableMap using the same underlying logic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46130 91177308-0d34-0410-b5e6-96231b3b80d8
and switch various codegen pieces and the X86 backend over
to using it.
* Add some comments to SelectionDAGNodes.h
* Introduce a second argument to FP_ROUND, which indicates
whether the FP_ROUND changes the value of its input. If
not it is safe to xform things like fp_extend(fp_round(x)) -> x.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46125 91177308-0d34-0410-b5e6-96231b3b80d8
ShortenEHDataFor64Bits as a not-very-accurate
abstraction to cover all the changes in DwarfWriter.
Some cosmetic changes to Darwin assembly code for
gcc testsuite compatibility.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46029 91177308-0d34-0410-b5e6-96231b3b80d8
drop attributes on varargs call arguments. Also, it could generate
invalid IR if the transformed call already had the 'nest' attribute
somewhere (this can never happen for code coming from llvm-gcc,
but it's a theoretical possibility). Fix both problems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45973 91177308-0d34-0410-b5e6-96231b3b80d8
parameter, even if it is a varargs function. Do
allow attributes on the varargs part of a call,
but not beyond the last argument. Only allow
selected attributes to be on the varargs part of
a call (currently only 'byval' is allowed). The
reasoning here is that most attributes, eg inreg,
simply make no sense here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45887 91177308-0d34-0410-b5e6-96231b3b80d8
- Cleaned up custom load/store logic, common code is now shared [see note
below], cleaned up address modes
- More test cases: various intrinsics, structure element access (load/store
test), updated target data strings, indirect function calls.
Note: This patch contains a refactoring of the LoadSDNode and StoreSDNode
structures: they now share a common base class, LSBaseSDNode, that
provides an interface to their common functionality. There is some hackery
to access the proper operand depending on the derived class; otherwise,
to do a proper job would require finding and rearranging the SDOperands
sent to StoreSDNode's constructor. The current refactor errs on the
side of being conservatively and backwardly compatible while providing
functionality that reduces redundant code for targets where loads and
stores are custom-lowered.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45851 91177308-0d34-0410-b5e6-96231b3b80d8
both work right according to the new flags.
This removes the TII::isReallySideEffectFree predicate, and adds
TII::isInvariantLoad.
It removes NeverHasSideEffects+MayHaveSideEffects and adds
UnmodeledSideEffects as machine instr flags. Now the clients
can decide everything they need.
I think isRematerializable can be implemented in terms of the
flags we have now, though I will let others tackle that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45843 91177308-0d34-0410-b5e6-96231b3b80d8
Likewise fix up a bunch of other libcalls. While
there I remove NEG_F32 and NEG_F64 since they are
not used anywhere. This fixes 9 Ada ACATS failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45833 91177308-0d34-0410-b5e6-96231b3b80d8
The first only returns definitions of a register, the second only
returns uses, the third returns both.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45803 91177308-0d34-0410-b5e6-96231b3b80d8
than hardware supported type will be scalarized, so we
can infer their alignment from that info.
We now codegen pr1845 into:
_boolVectorSelect:
lbz r2, 0(r3)
stb r2, -16(r1)
blr
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45796 91177308-0d34-0410-b5e6-96231b3b80d8
all clients over to using predicates instead of these flags directly.
These are now private values which are only to be used to statically
initialize the tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45692 91177308-0d34-0410-b5e6-96231b3b80d8
flags that can be set. Add predicates for the ones lacking it, and switch
some clients over to using the predicates instead of Flags directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45690 91177308-0d34-0410-b5e6-96231b3b80d8
TargetInstrDescriptor class and shrink to 16-bits, saving a
word in TargetInstrDescriptor. Add some comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45686 91177308-0d34-0410-b5e6-96231b3b80d8
over to using them, instead of diddling Flags directly. Change the
various flags from const variables to enums.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45677 91177308-0d34-0410-b5e6-96231b3b80d8
providing a misleading facility. It's used once in the MIPS backend
and hardcoded as "\t.globl\t" everywhere else.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45676 91177308-0d34-0410-b5e6-96231b3b80d8
that it is cheap and efficient to get.
Move a variety of predicates from TargetInstrInfo into
TargetInstrDescriptor, which makes it much easier to query a predicate
when you don't have TII around. Now you can use MI->getDesc()->isBranch()
instead of going through TII, and this is much more efficient anyway. Not
all of the predicates have been moved over yet.
Update old code that used MI->getInstrDescriptor()->Flags to use the
new predicates in many places.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45674 91177308-0d34-0410-b5e6-96231b3b80d8
up to the various compiler pipelines.
This doesn't actually add support for any GC algorithms, which means it
temporarily breaks a few tests. To be fixed shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45669 91177308-0d34-0410-b5e6-96231b3b80d8
direct calls bails out unless caller and callee have essentially
equivalent parameter attributes. This is illogical - the callee's
attributes should be of no relevance here. Rework the logic, which
incidentally fixes a crash when removed arguments have attributes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45658 91177308-0d34-0410-b5e6-96231b3b80d8
a direct call with cast parameters and cast return
value (if any), instcombine was prepared to cast any
non-void return value into any other, whether castable
or not. Add a new predicate for testing whether casting
is valid, and check it both for the return value and
(as a cleanup) for the parameters.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45657 91177308-0d34-0410-b5e6-96231b3b80d8
for non-function GV relocations that require function address stubs (e.g. Mac OS X in non-static mode).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45527 91177308-0d34-0410-b5e6-96231b3b80d8
own file. Don't #include ParameterAttributes.h into any major
public header files: just move methods out of line as appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45517 91177308-0d34-0410-b5e6-96231b3b80d8
it now returns the machineinstr of the use. To get the operand, use I.getOperand().
Add a new MachineRegisterInfo::replaceRegWith, which is basically like
Value::replaceAllUsesWith.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45482 91177308-0d34-0410-b5e6-96231b3b80d8
operands. The lists are currently kept in MachineRegisterInfo, but it does
not yet provide an iterator interface to them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45477 91177308-0d34-0410-b5e6-96231b3b80d8
a header file from libcodegen. This violates a layering order: codegen
depends on target, not the other way around. The fix to this is to
split TII into two classes, TII and TargetInstrInfoImpl, which defines
stuff that depends on libcodegen. It is defined in libcodegen, where
the base is not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45475 91177308-0d34-0410-b5e6-96231b3b80d8
that "machine" classes are used to represent the current state of
the code being compiled. Given this expanded name, we can start
moving other stuff into it. For now, move the UsedPhysRegs and
LiveIn/LoveOuts vectors from MachineFunction into it.
Update all the clients to match.
This also reduces some needless #includes, such as MachineModuleInfo
from MachineFunction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45467 91177308-0d34-0410-b5e6-96231b3b80d8
e.g. MO.isMBB() instead of MO.isMachineBasicBlock(). I don't plan on
switching everything over, so new clients should just start using the
shorter names.
Remove old long accessors, switching everything over to use the short
accessor: getMachineBasicBlock() -> getMBB(),
getConstantPoolIndex() -> getIndex(), setMachineBasicBlock -> setMBB(), etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45464 91177308-0d34-0410-b5e6-96231b3b80d8
- eliminate the auxInfo union, merging it into the contents union. This shaves
4 bytes off MachineOperand on a 32-bit machine.
- Use accessors in ctor methods.
- Add comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45462 91177308-0d34-0410-b5e6-96231b3b80d8
- Eliminate the static "print" method for operands, moving it
into MachineOperand::print.
- Change various set* methods for register flags to take a bool
for the value to set it to. Remove unset* methods.
- Group methods more logically by operand flavor in MachineOperand.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45461 91177308-0d34-0410-b5e6-96231b3b80d8
- Add getParent() accessors.
- Move SubReg out of the AuxInfo union, to make way for future changes.
- Remove the getImmedValue/setImmedValue methods.
- in some MachineOperand::Create* methods, stop initializing fields that are dead.
MachineInstr:
- Delete one copy of the MachineInstr printing code, now there is only one dump
format and one copy of the code.
- Make MachineOperand use the parent field to get info about preg register names if
no target info is otherwise available.
- Move def/use/kill/dead flag printing to the machineoperand printer, so they are
always printed for an operand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45460 91177308-0d34-0410-b5e6-96231b3b80d8
operand type.
2. Move these create methods below the accessors.
3. Simplify all the MachineInstr::add* methods to use these.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45430 91177308-0d34-0410-b5e6-96231b3b80d8
return attributes on the floor. In the case of a call
to a varargs function where the varargs arguments are
being removed, any call attributes on those arguments
need to be dropped. I didn't do this because I plan to
make it illegal to have such attributes (see next patch).
With this change, compiling the gcc filter2 eh test at -O0
and then running opt -std-compile-opts on it results in
a correctly working program (compiling at -O1 or higher
results in the test failing due to a problem with how we
output eh info into the IR).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45285 91177308-0d34-0410-b5e6-96231b3b80d8
calls 'nounwind'. It is important for correct C++
exception handling that nounwind markings do not get
lost, so this transformation is actually needed for
correctness.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45218 91177308-0d34-0410-b5e6-96231b3b80d8
Add comments to reset indicating that it deletes its pointer.
Add a new take() method, which can be used to get the pointer
without it being deleted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45112 91177308-0d34-0410-b5e6-96231b3b80d8
calls. Remove special casing of inline asm from the
inliner. There is a potential problem: the verifier
rejects invokes of inline asm (not sure why). If an
asm call is not marked "nounwind" in some .ll, and
instcombine is not run, but the inliner is run, then
an illegal module will be created. This is bad but
I'm not sure what the best approach is. I'm tempted
to remove the check in the verifier...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45073 91177308-0d34-0410-b5e6-96231b3b80d8
put it in a new header System/Host.h instead.
Instead of getting the endianness from configure,
calculate it directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44959 91177308-0d34-0410-b5e6-96231b3b80d8
regions of memory that have a target specific relationship, as described in the
Embedded C Technical Report.
This also implements the 2007-12-11-AddressSpaces test,
which demonstrates how address space attributes can be used in LLVM IR.
In addition, this patch changes the bitcode signature for stores (in a backwards
compatible manner), such that the pointer type, rather than the pointee type, is
encoded. This permits type information in the pointer (e.g. address space) to be
preserved for stores.
LangRef updates are forthcoming.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44858 91177308-0d34-0410-b5e6-96231b3b80d8
per-function collector model. Collector is now the factory for
CollectorMetadata, so the latter may be subclassed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44827 91177308-0d34-0410-b5e6-96231b3b80d8
don't have to #include config.h in it. #including config.h breaks
other projects that have their own autoconf stuff and try to #include
the llvm headers. One obscure example is llvm-gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44825 91177308-0d34-0410-b5e6-96231b3b80d8
Thompson. Usage should be something like this:
open Llvm
open Llvm_bitreader
match read_bitcode_file fn with
| Bitreader_failure msg ->
prerr_endline msg
| Bitreader_success m ->
...;
dispose_module m
Compile with: ocamlc llvm.cma llvm_bitreader.cma
ocamlopt llvm.cmxa llvm_bitreader.cmxa
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44824 91177308-0d34-0410-b5e6-96231b3b80d8
Reimplement the xform in Analysis/ConstantFolding.cpp where we can use
targetdata to validate that it is safe. While I'm in there, fix some const
correctness issues and generalize the interface to the "operand folder".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44817 91177308-0d34-0410-b5e6-96231b3b80d8
using the minimum possible number of bytes. For little
endian targets run on little endian machines, apints are
stored in memory from LSB to MSB as before. For big endian
targets on big endian machines they are stored from MSB to
LSB which wasn't always the case before (if the target and
host endianness doesn't match values are stored according
to the host's endianness). Doing this requires knowing the
endianness of the host, which is determined when configuring -
thanks go to Anton for this. Only having access to little
endian machines I was unable to properly test the big endian
part, which is also the most complicated...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44796 91177308-0d34-0410-b5e6-96231b3b80d8
methods are new to Function:
bool hasCollector() const;
const std::string &getCollector() const;
void setCollector(const std::string &);
void clearCollector();
The assembly representation is as such:
define void @f() gc "shadow-stack" { ...
The implementation uses an on-the-side table to map Functions to
collector names, such that there is no overhead. A StringPool is
further used to unique collector names, which are extremely
likely to be unique per process.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44769 91177308-0d34-0410-b5e6-96231b3b80d8
_sabre_: it has a major problem: by the time ~Value is run, all of the "parts" of the derived classes have been destroyed
_sabre_: the vtable lives to fight another day
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44760 91177308-0d34-0410-b5e6-96231b3b80d8
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
Deserialize::ReadDiffPtrID to read and emit bools instead of unsigned
integers. This should result in a nice space optimization once we have
"auto-abbreviation" generation in place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44200 91177308-0d34-0410-b5e6-96231b3b80d8
SerializedPtrID, followed by the *differences* in IDs. The big idea is that
most IDs will be just be 1 off from the previous (either that or NULL, which
we encode as a difference if 0), so this will greatly reduce the encoding
space for extra IDs to just 1 bit per pointer.
So far this optimization reduces serialization of Carbon.h by only 1%, but
we aren't using any abbreviations now in the Bitcode file to properly take
advantage of this optimization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44199 91177308-0d34-0410-b5e6-96231b3b80d8
When a live interval is being spilled, rather than creating short, non-spillable
intervals for every def / use, split the interval at BB boundaries. That is, for
every BB where the live interval is defined or used, create a new interval that
covers all the defs and uses in the BB.
This is designed to eliminate one common problem: multiple reloads of the same
value in a single basic block. Note, it does *not* decrease the number of spills
since no copies are inserted so the split intervals are *connected* through
spill and reloads (or rematerialization). The newly created intervals can be
spilled again, in that case, since it does not span multiple basic blocks, it's
spilled in the usual manner. However, it can reuse the same stack slot as the
previously split interval.
This is currently controlled by -split-intervals-at-bb.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44198 91177308-0d34-0410-b5e6-96231b3b80d8
is disabled in the sense that it will refuse to create one from a UDiv
instruction, until the code is better tested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44163 91177308-0d34-0410-b5e6-96231b3b80d8
deserialize objects if BatchReadOwnedPtrs was called more than once in the
same call chain then the second call would overwrite the SerializedPtrIDs
being used by the first call. Solved this problem by making the vector that
holds the pointer IDs local to a function call. Now BatchReadOwnedPtrs is
reentrant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44152 91177308-0d34-0410-b5e6-96231b3b80d8
MachineOperand auxInfo. Previous clunky implementation uses an external map
to track sub-register uses. That works because register allocator uses
a new virtual register for each spilled use. With interval splitting (coming
soon), we may have multiple uses of the same register some of which are
of using different sub-registers from others. It's too fragile to constantly
update the information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44104 91177308-0d34-0410-b5e6-96231b3b80d8
to use different mappings for EH and debug info;
no functional change yet.
Fix warning in X86CodeEmitter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44056 91177308-0d34-0410-b5e6-96231b3b80d8
adjustment fields, and an optional flag. If there is a "dynamic_stackalloc" in
the code, make sure that it's bracketed by CALLSEQ_START and CALLSEQ_END. If
not, then there is the potential for the stack to be changed while the stack's
being used by another instruction (like a call).
This can only result in tears...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44037 91177308-0d34-0410-b5e6-96231b3b80d8
clients of the Deserializer to read the pointer ID before they are ready
to deserialize the object (which can mean registering a pointer reference
with the backpatcher).
Changed some methods that took an argument "SerializedPtrID" to "const SerializedPtrID&" (pass-by-reference). This is to accommodate a future
revision of SerializedPtrID where it may be much fatter than an unsigned
integer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44021 91177308-0d34-0410-b5e6-96231b3b80d8
deserialization as a temporary location for storing serialized pointer identifiers. The
definition of SerializedPtrID will likely change significantly in the future, and the
current implementation caused compilation errors on some 64-bit machines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43983 91177308-0d34-0410-b5e6-96231b3b80d8
serialized block in the bitstream, including a block in an entirely different
nesting than the current block. This is useful for deserializing objects from
a bitstream in an order different from the order that they were serialized.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43973 91177308-0d34-0410-b5e6-96231b3b80d8
Moved some of the logic in BitstreamReader::ExitBlock into a utility function
BitstreamReader::PopBlockScope. The latter is a private method. It will also
be called by Deserializer to manipulate the current "block scope."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43972 91177308-0d34-0410-b5e6-96231b3b80d8
apints on big-endian machines if the bitwidth is
not a multiple of 8. Introduce a new helper,
MVT::getStoreSizeInBits, and use it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43934 91177308-0d34-0410-b5e6-96231b3b80d8
block that is being visited in the bitstream. The client can also now
skip blocks before reading them, and query the current abbreviation number
as seen from the perspective of the Deserializer. This allows the client
to be more interactive in the deserialization process (if they so choose).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43916 91177308-0d34-0410-b5e6-96231b3b80d8
instead of just using "unsigned". This gives us more flexibility in changing
the definition of the handle later, and is more self-documenting.
Added tracking of block stack in the Deserializer. Now clients can query
if they are still within a block using the methods GetCurrentBlockLocation()
and FinishedBlock().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43903 91177308-0d34-0410-b5e6-96231b3b80d8
array of pointers to not allocate a second array to contain the pointer ids.
Fixed bug in the same member function where deserialized pointers were
not being registered with the backpatcher.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43855 91177308-0d34-0410-b5e6-96231b3b80d8
to group the pointer IDs together in the bitstream before their referenced
contents (which will lend itself to more efficient encoding).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43845 91177308-0d34-0410-b5e6-96231b3b80d8
by value. This version prohibits backpatching of pointers, so it
useful when a pointee is always known to be deserialized beforehand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43799 91177308-0d34-0410-b5e6-96231b3b80d8
should only effect x86 when using long double. Now
12/16 bytes are output for long double globals (the
exact amount depends on the alignment). This brings
globals in line with the rest of LLVM: the space
reserved for an object is now always the ABI size.
One tricky point is that only 10 bytes should be
output for long double if it is a field in a packed
struct, which is the reason for the additional
argument to EmitGlobalConstant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43688 91177308-0d34-0410-b5e6-96231b3b80d8
or getTypeSizeInBits as appropriate in ScalarReplAggregates.
The right change to make was not always obvious, so it would
be good to have an sroa guru review this. While there I noticed
some bugs, and fixed them: (1) arrays of x86 long double have
holes due to alignment padding, but this wasn't being spotted
by HasStructPadding (renamed to HasPadding). The same goes
for arrays of oddly sized ints. Vectors also suffer from this,
in fact the problem for vectors is much worse because basic
vector assumptions seem to be broken by vectors of type with
alignment padding. I didn't try to fix any of these vector
problems. (2) The code for extracting smaller integers from
larger ones (in the "int union" case) was wrong on big-endian
machines for integers with size not a multiple of 8, like i1.
Probably this is impossible to hit via llvm-gcc, but I fixed
it anyway while there and added a testcase. I also got rid of
some trailing whitespace and changed a function name which
had an obvious typo in it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43672 91177308-0d34-0410-b5e6-96231b3b80d8
can be eliminated by the allocator is the destination and source targets the
same register. The most common case is when the source and destination registers
are in different class. For example, on x86 mov32to32_ targets GR32_ which
contains a subset of the registers in GR32.
The allocator can do 2 things:
1. Set the preferred allocation for the destination of a copy to that of its source.
2. After allocation is done, change the allocation of a copy destination (if
legal) so the copy can be eliminated.
This eliminates 443 extra moves from 403.gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43662 91177308-0d34-0410-b5e6-96231b3b80d8
the target pointer to be passed by reference. This can result in less
typing, as the object to be deserialized can be inferred from the
argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43647 91177308-0d34-0410-b5e6-96231b3b80d8
memory rather than in a copy of the APFloat. This avoids problems
when the destination is wider than our significand and is cleaner.
Also provide deterministic values in all cases where conversion
fails, namely zero for NaNs and the minimal or maximal value
respectively for underflow or overflow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43626 91177308-0d34-0410-b5e6-96231b3b80d8
Deserializer.
There were issues with Visual C++ barfing when instantiating
SerializeTrait<T> when "T" was an abstract class AND
SerializeTrait<T>::ReadVal was *never* called:
template <typename T>
struct SerializeTrait {
<SNIP>
static inline T ReadVal(Deserializer& D) { T::ReadVal(D); }
<SNIP>
};
Visual C++ would complain about "T" being an abstract class, even
though ReadVal was never instantiated (although one of the other
member functions were).
Removing this from the trait is not a big deal. It was used hardly
ever, and users who want "read-by-value" deserialization can simply
call the appropriate methods directly instead of relying on
trait-based-dispatch. The trait dispatch for
serialization/deserialization is simply sugar in many cases (like this
one).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43624 91177308-0d34-0410-b5e6-96231b3b80d8