of manually doing padding/editing layout in LayoutSection().
- This probably seems like six-of-one and half-dozen of another, but there
is a method to my madness.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103693 91177308-0d34-0410-b5e6-96231b3b80d8
ParseDirectiveDarwinZerofill instead of hard coding the
check for identifier. This allows quoted symbol names to
be used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103682 91177308-0d34-0410-b5e6-96231b3b80d8
lower them to the correct x86-64 instructions since we
don't have a clean way to handle this in td files yet.
rdar://7947184
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103668 91177308-0d34-0410-b5e6-96231b3b80d8
on RAUW of functions, this is a correctness issue instead of a mere memory
usage problem.
No testcase until the new MergeFunctions can land.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103653 91177308-0d34-0410-b5e6-96231b3b80d8
Made a stylistic changed to the code/comments related to the unsupported COMDAT selection type IMAGE_COMDAT_SELECT_LARGEST based on from Anton Korobeynikov.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103590 91177308-0d34-0410-b5e6-96231b3b80d8
Now, the .linkonce directive is emitted as part of MCSectionCOFF::PrintSwitchToSection instead of AsmPrinter::EmitLinkage since it is an attribute of the section the symbol was placed into not the symbol itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103568 91177308-0d34-0410-b5e6-96231b3b80d8
v1024 = REG_SEQUENCE ...
v1025 = EXTRACT_SUBREG v1024, 5
v1026 = EXTRACR_SUBREG v1024, 6
= VSTxx <addr>, v1025, v1026
The REG_SEQUENCE ensures the sources that feed into the VST instruction
are getting the right register allocation so they form a large super-
register. The extract_subreg will be coalesced away all would just work:
v1024 = REG_SEQUENCE ...
= VSTxx <addr>, v1024:5, v1024:6
The problem is if the coalescer isn't run, the extract_subreg instructions
would stick around and there is no assurance v1025 and v1026 will get the
right registers.
As a short term workaround, teach the NEON pre-allocation pass to transfer
the sub-register indices over. An alternative would be do it 2addr pass
when reg_sequence's are eliminated. But that *seems* wrong and require
updating liveness information.
Another alternative is to do this in the scheduler when the instructions are
created. But that would mean somehow the scheduler this has to be done for
correctness reason. That's yucky as well. So for now, we are leaving this
in the target specific pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103540 91177308-0d34-0410-b5e6-96231b3b80d8
be diced into atoms, and adjust getAtom() to take this into account.
- This fixes relocations to symbols in fixed size literal sections, for
example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103532 91177308-0d34-0410-b5e6-96231b3b80d8
This allows us to add accurate kill markers, something the scavenger likes.
Add some more tests from ARM that needed this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103521 91177308-0d34-0410-b5e6-96231b3b80d8
create separate virtual registers for CopyFromReg values, so uses of
them don't necessarily kill the value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103519 91177308-0d34-0410-b5e6-96231b3b80d8
to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is
the opposite, for future use by dragonegg.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103495 91177308-0d34-0410-b5e6-96231b3b80d8
and the others use the regular addPassesToEmitFile hook now, and
llc no longer needs a bunch of redundant code to handle the
whole-file case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103492 91177308-0d34-0410-b5e6-96231b3b80d8
Sorry for the big change. The path leading up to this patch had some TableGen
changes that I didn't want to commit before I knew they were useful. They
weren't, and this version does not need them.
The fast register allocator now does no liveness calculations. Instead it relies
on kill flags provided by isel. (Currently those kill flags are also ignored due
to isel bugs). The allocation algorithm is supposed to work with any subset of
valid kill flags. More kill flags simply means fewer spills inserted.
Registers are allocated from a working set that contains no aliases. That means
most allocations can be done directly without expensive alias checks. When the
working set runs out of registers we do the full alias check to find new free
registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103488 91177308-0d34-0410-b5e6-96231b3b80d8
Move EmitTargetCodeForMemcpy, EmitTargetCodeForMemset, and
EmitTargetCodeForMemmove out of TargetLowering and into
SelectionDAGInfo to exercise this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103481 91177308-0d34-0410-b5e6-96231b3b80d8
- This eliminates getAtomForAddress() (which was a linear search) and
simplifies getAtom().
- This also fixes some correctness problems where local labels at the same
address as non-local labels could be assigned to the wrong atom.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103480 91177308-0d34-0410-b5e6-96231b3b80d8
string of features for that target. However LTO was using that string to pass
into the "create target machine" stuff. That stuff needed the feature string to
be in a particular form. In particular, it needed the CPU specified first and
then the attributes. If there isn't a CPU specified, it required it to be blank
-- e.g., ",+altivec". Yuck.
Modify the getDefaultSubtargetFeatures method to be a non-static member
function. For all attributes for a specific subtarget, it will add them in like
normal. It will also take a CPU string so that it can satisfy this horrible
syntax.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103451 91177308-0d34-0410-b5e6-96231b3b80d8
This includes a patch by Roman Divacky to fix the initial crash.
Move the actual addition of passes from *PassManager::add to
*PassManager::addImpl. That way, when adding printer passes we won't
recurse infinitely.
Finally, check to make sure that we are actually adding a FunctionPass
to a FunctionPassManager before doing a print before or after it.
Immutable passes are strange in this way because they aren't
FunctionPasses yet they can be and are added to the FunctionPassManager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103425 91177308-0d34-0410-b5e6-96231b3b80d8
- Disables 'Built on ...' in 'foo --version'.
- Disables timestamps from being embedded into .dir files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103423 91177308-0d34-0410-b5e6-96231b3b80d8
SSAUpdater for the value from the first def may see uses of undefined values,
because the later defs will not have been updated yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103407 91177308-0d34-0410-b5e6-96231b3b80d8
changed dllexport code to use EmitBytes instead of EmitRawText, and changed the export option to use /EXPORT: instead of -export: on the windows platform
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103377 91177308-0d34-0410-b5e6-96231b3b80d8
when it detects undefined behavior. llvm.trap generally codegens into some
thing really small (e.g. a 2 byte ud2 instruction on x86) and debugging this
sort of thing is "nontrivial". For example, we now compile:
void foo() { *(int*)0 = 42; }
into:
_foo:
pushl %ebp
movl %esp, %ebp
ud2
Some may even claim that this is a security hole, though that seems dubious
to me. This addresses rdar://7958343 - Optimizing away null dereference
potentially allows arbitrary code execution
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103356 91177308-0d34-0410-b5e6-96231b3b80d8
with a vector input and output into a shuffle vector. This sort of
sequence happens when the input code stores with one type and reloads
with another type and then SROA promotes to i96 integers, which make
everyone sad.
This fixes rdar://7896024
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103354 91177308-0d34-0410-b5e6-96231b3b80d8
LSRUse's Regs set after all pruning is done, rather than trying
to do it on the fly, which can produce an incomplete result.
This fixes a case where heuristic pruning was stripping all
formulae from a use, which led the solver to enter an infinite
loop.
Also, add a few asserts to diagnose this kind of situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103328 91177308-0d34-0410-b5e6-96231b3b80d8
