PIC16Section class", it breaks globals.ll.

llvm-svn: 84184

derived from MCSection.

llvm-svn: 84180

llvm-svn: 84179

llvm-svn: 84173

When ARMConstantIslandPass cannot find any good locations (i.e., "water") to
place constants, it falls back to inserting unconditional branches to make a
place to put them.  My recent change exposed a problem in this area.  We may
sometimes append to the same block more than one unconditional branch.  The
symptoms of this are that the generated assembly has a branch to an undefined
label and running llc with -debug will cause a seg fault.

This happens more easily since my change to prevent CPEs from moving from
lower to higher addresses as the algorithm iterates, but it could have
happened before.  The end of the block may be in range for various constant
pool references, but the insertion point for new CPEs is not right at the end
of the block -- it is at the end of the CPEs that have already been placed
at the end of the block.  The insertion point could be out of range.  When
that happens, the fallback code will always append another unconditional
branch if the end of the block is in range.

The fix is to only append an unconditional branch if the block does not
already end with one.  I also removed a check to see if the constant pool load
instruction is at the end of the block, since that is redundant with
checking if the end of the block is in-range.

There is more to be done here, but I think this fixes the immediate problem.

llvm-svn: 84172

Patch by Johnny Chen.

llvm-svn: 84146

llvm-svn: 84144

Refs: A7-17 & A8-750.

Patch by Johnny Chen.

llvm-svn: 84131

register-shifted-register instructions.  Patch by Johnny Chen.

llvm-svn: 84124

llvm-svn: 84122

llvm-svn: 84117

vld lane intrinsics.

llvm-svn: 84110

llvm-svn: 84109

(for uses marked kill and defs marked dead) a few instructions in
addition to forwards. Also, increase the maximum number of instructions
to scan, as it appears to help in a fair number of cases.

llvm-svn: 84061

llvm-svn: 84055

s/DebugLoc.InlinedLoc/DebugLoc.InlinedAtLoc/g

llvm-svn: 84054

by creating TargetConstants during instruction selection instead of during
legalization.

llvm-svn: 84042

Also fixed a couple of coding style things that crept in.  And added more
to the temporary hacked up ARMAsmParser::MatchInstruction() method for testing.

llvm-svn: 84040

multiple instructions, the expansion is done during selection so there is
no need to do anything special during legalization.

llvm-svn: 84036

be in a register.  The previous use of ARM address mode 2 was completely
arbitrary and inappropriate for Thumb.  Radar 7137468.

llvm-svn: 84022

llvm-svn: 84017

llvm-svn: 84009

llvm-svn: 84008

Patch by Johnny Chen.

llvm-svn: 83983

llvm-svn: 83982

llvm-svn: 83973

llvm-svn: 83917

before its reference is only supported on ARM has not been true for a while.
In fact, until recently, that was only supported for Thumb.  Besides that,
CPEs are always a multiple of 4 bytes in size, so inserting a CPE should have
no effect on Thumb alignment.

llvm-svn: 83916

should have been a pointer to a reference.

llvm-svn: 83915

llvm-svn: 83905

MultiSource/Benchmarks/MiBench/automotive-susan test.  The failure has
since been masked by an unrelated change (just randomly), so I don't have
a testcase for this now.  Radar 7291928.

The situation where this happened is that a constant pool entry (CPE) was
placed at a lower address than the load that referenced it.  There were in
fact 2 CPEs placed at adjacent addresses and referenced by 2 loads that were
close together in the code.  The distance from the loads to the CPEs was
right at the limit of what they could handle, so that only one of the CPEs
could be placed within range.  On every iteration, the first CPE was found
to be out of range, causing a new CPE to be inserted.  The second CPE had
been in range but the newly inserted entry pushed it too far away.  Thus the
second CPE was also replaced by a new entry, which in turn pushed the first
CPE out of range.  Etc.

Judging from some comments in the code, the initial implementation of this
pass did not support CPEs placed _before_ their references.  In the case
where the CPE is placed at a higher address, the key to making the algorithm
terminate is that new CPEs are only inserted at the end of a group of adjacent
CPEs.  This is implemented by removing a basic block from the "WaterList"
once it has been used, and then adding the newly inserted CPE block to the
list so that the next insertion will come after it.  This avoids the ping-pong
effect where CPEs are repeatedly moved to the beginning of a group of
adjacent CPEs.  This does not work when going backwards, however, because the
entries at the end of an adjacent group of CPEs are closer than the CPEs
earlier in the group.

To make this pass terminate, we need to maintain a property that changes can
only happen in some sort of monotonic fashion.  The fix used here is to require
that the CPE for a particular constant pool load can only move to lower
addresses.  This is a very simple change to the code and should not cause
any significant degradation in the results.

llvm-svn: 83902

llvm-svn: 83897

llvm-svn: 83894

llvm-svn: 83874

llvm-svn: 83873

llvm-svn: 83872

bootstrap of FSF-style PPC, so there is some
reason to believe the original bug (which was
never analyzed) has been fixed, probably by
82266.

llvm-svn: 83871

it to hold the address of an sret return value, for x86-64 ABI purposes.

Also, fix the test that was originally intended to test this to actually
test it, using FileCheck.

llvm-svn: 83853

llvm-svn: 83822

llvm-svn: 83812