Commit Graph

167 Commits

Author SHA1 Message Date
NAKAMURA Takumi
f3f355dd95 llvm/test/CodeGen/XCore/dwarf_debug.ll: Fix not to be affected by *-win32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212335 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-04 11:58:03 +00:00
Robert Lytton
546cfbfd0a XCore target: remove incorrect DebugLoc entries from prologue
Summary: This was causing the prologue_end to be incorrectly positioned.

Differential Revision: http://reviews.llvm.org/D4122

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212318 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-04 06:38:22 +00:00
Alp Toker
8aeca44558 Reduce verbiage of lit.local.cfg files
We can just split targets_to_build in one place and make it immutable.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210496 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-09 22:42:55 +00:00
Duncan P. N. Exon Smith
9a11d668f9 Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"
This reverts commit r206707, reapplying r206704.  The preceding commit
to CalcSpillWeights should have sorted out the failing buildbots.

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206766 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-21 17:57:07 +00:00
Duncan P. N. Exon Smith
f44eda4764 Revert "blockfreq: Rewrite BlockFrequencyInfoImpl"
This reverts commit r206704, as expected.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206707 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-19 22:46:00 +00:00
Duncan P. N. Exon Smith
f465370a49 Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"
This reverts commit r206677, reapplying my BlockFrequencyInfo rewrite.

I've done a careful audit, added some asserts, and fixed a couple of
bugs (unfortunately, they were in unlikely code paths).  There's a small
chance that this will appease the failing bots [1][2].  (If so, great!)

If not, I have a follow-up commit ready that will temporarily add
-debug-only=block-freq to the two failing tests, allowing me to compare
the code path between what the failing bots and what my machines (and
the rest of the bots) are doing.  Once I've triggered those builds, I'll
revert both commits so the bots go green again.

[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816
[2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206704 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-19 22:34:26 +00:00
Duncan P. N. Exon Smith
2033057de8 Revert "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)
This reverts commit r206666, as planned.

Still stumped on why the bots are failing.  Sanitizer bots haven't
turned anything up.  If anyone can help me debug either of the failures
(referenced in r206666) I'll owe them a beer.  (In the meantime, I'll be
auditing my patch for undefined behaviour.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206677 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-19 00:42:46 +00:00
Duncan P. N. Exon Smith
036e26bc29 Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)
This reverts commit r206628, reapplying r206622 (and r206626).

Two tests are failing only on buildbots [1][2]: i.e., I can't reproduce
on Darwin, and Chandler can't reproduce on Linux.  Asan and valgrind
don't tell us anything, but we're hoping the msan bot will catch it.

So, I'm applying this again to get more feedback from the bots.  I'll
leave it in long enough to trigger builds in at least the sanitizer
buildbots (it was failing for reasons unrelated to my commit last time
it was in), and hopefully a few others.... and then I expect to revert a
third time.

[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816
[2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206666 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-18 22:30:03 +00:00
Duncan P. N. Exon Smith
ebb5d29473 Revert "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)
This reverts commit r206622 and the MSVC fixup in r206626.

Apparently the remotely failing tests are still failing, despite my
attempt to fix the nondeterminism in r206621.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206628 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-18 17:56:08 +00:00
Duncan P. N. Exon Smith
54850bedf2 Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"
This reverts commit r206556, effectively reapplying commit r206548 and
its fixups in r206549 and r206550.

In an intervening commit I've added target triples to the tests that
were failing remotely [1] (but passing locally).  I'm hoping the mystery
is solved?  I'll revert this again if the tests are still failing
remotely.

[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206622 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-18 17:22:25 +00:00
Duncan P. N. Exon Smith
c7a3b95c0f Revert "blockfreq: Rewrite BlockFrequencyInfoImpl"
This reverts commits r206548, r206549 and r206549.

There are some unit tests failing that aren't failing locally [1], so
reverting until I have time to investigate.

[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206556 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-18 02:17:43 +00:00
Duncan P. N. Exon Smith
cc1e1707b8 blockfreq: Rewrite BlockFrequencyInfoImpl
Rewrite the shared implementation of BlockFrequencyInfo and
MachineBlockFrequencyInfo entirely.

The old implementation had a fundamental flaw:  precision losses from
nested loops (or very wide branches) compounded past loop exits (and
convergence points).

The @nested_loops testcase at the end of
test/Analysis/BlockFrequencyAnalysis/basic.ll is motivating.  This
function has three nested loops, with branch weights in the loop headers
of 1:4000 (exit:continue).  The old analysis gives non-sensical results:

    Printing analysis 'Block Frequency Analysis' for function 'nested_loops':
    ---- Block Freqs ----
     entry = 1.0
     for.cond1.preheader = 1.00103
     for.cond4.preheader = 5.5222
     for.body6 = 18095.19995
     for.inc8 = 4.52264
     for.inc11 = 0.00109
     for.end13 = 0.0

The new analysis gives correct results:

    Printing analysis 'Block Frequency Analysis' for function 'nested_loops':
    block-frequency-info: nested_loops
     - entry: float = 1.0, int = 8
     - for.cond1.preheader: float = 4001.0, int = 32007
     - for.cond4.preheader: float = 16008001.0, int = 128064007
     - for.body6: float = 64048012001.0, int = 512384096007
     - for.inc8: float = 16008001.0, int = 128064007
     - for.inc11: float = 4001.0, int = 32007
     - for.end13: float = 1.0, int = 8

Most importantly, the frequency leaving each loop matches the frequency
entering it.

The new algorithm leverages BlockMass and PositiveFloat to maintain
precision, separates "probability mass distribution" from "loop
scaling", and uses dithering to eliminate probability mass loss.  I have
unit tests for these types out of tree, but it was decided in the review
to make the classes private to BlockFrequencyInfoImpl, and try to shrink
them (or remove them entirely) in follow-up commits.

The new algorithm should generally have a complexity advantage over the
old.  The previous algorithm was quadratic in the worst case.  The new
algorithm is still worst-case quadratic in the presence of irreducible
control flow, but it's linear without it.

The key difference between the old algorithm and the new is that control
flow within a loop is evaluated separately from control flow outside,
limiting propagation of precision problems and allowing loop scale to be
calculated independently of mass distribution.  Loops are visited
bottom-up, their loop scales are calculated, and they are replaced by
pseudo-nodes.  Mass is then distributed through the function, which is
now a DAG.  Finally, loops are revisited top-down to multiply through
the loop scales and the masses distributed to pseudo nodes.

There are some remaining flaws.

  - Irreducible control flow isn't modelled correctly.  LoopInfo and
    MachineLoopInfo ignore irreducible edges, so this algorithm will
    fail to scale accordingly.  There's a note in the class
    documentation about how to get closer.  See also the comments in
    test/Analysis/BlockFrequencyInfo/irreducible.ll.

  - Loop scale is limited to 4096 per loop (2^12) to avoid exhausting
    the 64-bit integer precision used downstream.

  - The "bias" calculation proposed on llvmdev is *not* incorporated
    here.  This will be added in a follow-up commit, once comments from
    this review have been handled.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206548 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-18 01:57:45 +00:00
Richard Osborne
c9fa660ddd [XCore] Don't create invalid MKMSK instructions inside loadImmediate().
Summary:
Previously loadImmediate() would produce MKMSK instructions with invalid
immediate values such as mkmsk r0, 9. Fix this by checking the mask size
is valid.

Reviewers: robertlytton

Reviewed By: robertlytton

CC: llvm-commits

Differential Revision: http://reviews.llvm.org/D3289

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206163 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-14 12:30:35 +00:00
Richard Osborne
d530a96701 [XCore] Add support for the "m" inline asm constraint.
Summary:
This provides support for CP and DP relative global accesses in inline
asm.

Reviewers: robertlytton

Reviewed By: robertlytton

Differential Revision: http://llvm-reviews.chandlerc.com/D2943

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-06 16:37:48 +00:00
Richard Osborne
f41c05c7ca [XCore] Fix call of absolute address.
Previously for:

tail call void inttoptr (i64 65536 to void ()*)() nounwind

We would emit:

bl 65536

The immediate operand of the bl instruction is a relative offset so it is
wrong to use the absolute address here.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202860 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-04 16:50:30 +00:00
Richard Osborne
cc331c8f40 [XCore] Support functions returning more than 4 words.
If a function returns a large struct by value return the first 4 words
in registers and the rest on the stack in a location reserved by the
caller. This is needed to support the xC language which supports
functions returning an arbitrary number of return values. This is
r202397 reapplied with a fix to avoid an uninitialized read of a member.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202414 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 17:47:54 +00:00
Richard Osborne
e4db795a4c Revert r202396, r202397.
These are causing test failures, revert for now.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202398 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 14:24:13 +00:00
Richard Osborne
ad4ffce35f [XCore] Support functions returning more than 4 words.
Summary:
If a function returns a large struct by value return the first 4 words
in registers and the rest on the stack in a location reserved by the
caller. This is needed to support the xC language which supports
functions returning an arbitrary number of return values.

Reviewers: robertlytton

Reviewed By: robertlytton

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2889

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202397 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 14:00:40 +00:00
Richard Osborne
c26292d4dc [XCore] Target optimized library function __memcpy_4()
Summary:
If the src, dst and size of a memcpy are known to be 4 byte aligned we
can call __memcpy_4() instead of memcpy().

Reviewers: robertlytton

Reviewed By: robertlytton

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2871

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202395 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 13:39:07 +00:00
Richard Osborne
83eab939a4 [XCore] Add dag combines for instructions that ignore some input bits.
These instructions ignore the high bits of one of their input operands -
try and use this to simplify the code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202394 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 13:20:11 +00:00
Richard Osborne
ef174f733a [XCore] Provide information about known zero bits of resource instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202393 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 13:20:06 +00:00
Andrew Trick
9ad6bda08e Use regnum regex in an XCore test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202315 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-26 23:22:49 +00:00
Andrew Trick
aa115a7fbf Very temporarily XFAILing a test. Will be fixed shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202310 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-26 22:39:59 +00:00
Richard Osborne
150f810744 [XCore] Add intrinsic for CLRPT (clear port time) instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202172 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-25 17:31:15 +00:00
Richard Osborne
fb2f73acb9 [XCore] Add intrinsic for EDU (event disable unconditional) instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202171 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-25 17:31:06 +00:00
Richard Osborne
6dc9f732ce [XCore] Prefer to word align functions.
The behaviour of the XCore's instruction buffer means that the performance
of the same code sequence can differ depending on whether it starts at a 4
byte aligned address or not. Since we don't model the instruction buffer
in the backend we have no way of knowing for sure if it is beneficial to
word align a specific function. However, in the absence of precise
modelling, it is better on balance to word align functions because:

* It makes a fetch-nop while executing the prologue slightly less likely.
* If we don't word align functions then a small perturbation in one
  function can have a dramatic knock on effect. If the size of the function
  changes it might change the alignment and therefore the performance of
  all the functions that happen to follow it in the binary. This butterfly
  effect makes it harder to reason about and measure the performance of
  code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202163 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-25 16:37:15 +00:00
Robert Lytton
ade82a4157 XCore target: Handle common linkage
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201563 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-18 11:21:59 +00:00
Robert Lytton
9409825b57 XCore target: Fix llvm.eh.return and EH info register handling
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201561 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-18 11:21:48 +00:00
Robert Lytton
d3abd0b648 XCore target: fix const section handling
Xcore target ABI requires const data that is externally visible
to be handled differently if it has C-language linkage rather than
C++ language linkage.

Clang now emits ".cp.rodata" section information.

All other externally visible constant data will be placed in the DP section.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201144 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-11 10:36:26 +00:00
Robert Lytton
04a573a41f XCore target: Lower ATOMIC_LOAD & ATOMIC_STORE
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201143 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-11 10:36:18 +00:00
Benjamin Kramer
ccdb9c9483 Fix broken CHECK lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199016 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-11 21:06:00 +00:00
Robert Lytton
f1c1a7ce44 XCore Target: correct callee save register spilling when callsUnwindInit is true.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198616 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-06 14:21:12 +00:00
Robert Lytton
3a905cbce6 XCore target: Lower EH_RETURN
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198615 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-06 14:21:07 +00:00
Robert Lytton
af74cbf553 XCore target: Lower FRAME_TO_ARGS_OFFSET
This requires a knowledge of the stack size which is not known until
the frame is complete, hence the need for the XCoreFTAOElim pass
which lowers the XCoreISD::FRAME_TO_ARGS_OFFSET instrution into its
final form.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198614 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-06 14:21:00 +00:00
Robert Lytton
12ad7cd730 XCore target: Lower RETURNADDR
Only handles a depth of zero (the same as FRAMEADDR)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198613 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-06 14:20:53 +00:00
Robert Lytton
c2508e505a XCore target: Optimise entsp / retsp selection
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198612 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-06 14:20:47 +00:00
Robert Lytton
e452d6e547 XCore target: fix handling of unsized global arrays in large code model
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198609 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-06 14:20:32 +00:00
Robert Lytton
f19c6f5763 XCore target: Make handling of large frames not dependent upon an FP.
eliminateFrameIndex() has been reworked to handle both small & large frames
with either a FP or SP.
An additional Slot is required for Scavenging spills when not using FP for large frames.
Reworked the handling of Register Scavenging.

Whether we are using an FP or not, whether it is a large frame or not,
and whether we are using a large code model or not are now independent.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196091 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-02 11:05:28 +00:00
Robert Lytton
41d4ed4ed0 XCore target: fix large code model 'select' indirect address handling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196088 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-02 10:18:37 +00:00
Robert Lytton
883abacb5b XCore target: Add large code model
When using large code model:
Global objects larger than 'CodeModelLargeSize' bytes are placed in sections named with a trailing ".large"
The folded global address of such objects are lowered into the const pool.

During inspection it was noted that LowerConstantPool() was using a default offset of zero.
A fix was made, but due to only offsets of zero being generated, testing only verifies the change is not detrimental.

Correct the flags emitted for explicitly specified sections.

We assume the size of the object queried by getSectionForConstant() is never greater than CodeModelLargeSize.
To handle greater than CodeModelLargeSize, changes to AsmPrinter would be required.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196087 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-02 10:18:31 +00:00
Robert Lytton
7112fa0523 XCore target: extend tests in preparation
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196086 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-02 10:18:24 +00:00
Robert Lytton
25464b948f XCore target: Fix eliminateFrameIndex() to handle large frames
Large frame offsets are loaded from the ConstantPool.
Where possible, offsets are encoded using the smaller MKMSK instruction.
Large frame offsets can only be used when there is a frame-pointer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196085 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-02 10:18:19 +00:00
Robert Lytton
1326c6f14b XCore target: Enable frames larger than 65535 to be lowered
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196084 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-02 10:18:14 +00:00
Rafael Espindola
3d47402f2e Error if we see an alias to a declaration.
In ELF and COFF an alias is just another offset in a section. There is no way
to represent an alias to something in another file.

In MachO, the spec has the N_INDR type which should allow for exactly that, but
is not currently implemented. Given that it is specified but not implemented,
we error in codegen to avoid miscompiling but don't reject aliases to
declarations in the verifier to leave the option open of implementing it.

In the past we have used alias to declarations as a way of implementing
weakref, which is why it exists in some old tests which this patch updates.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194705 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-14 13:58:06 +00:00
Robert Lytton
8b99622b9b XCore target: implement exception handling
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194564 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-13 10:19:31 +00:00
Robert Lytton
47a4349eb6 XCore target: fix bug in aligning 'byval i8*' on the stack
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194466 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-12 10:11:35 +00:00
Robert Lytton
092815ce4b XCore target test for hidden declaration
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194465 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-12 10:11:30 +00:00
Robert Lytton
32e8528c33 Add XCore support for ATOMIC_FENCE.
ATOMIC_FENCE is lowered to a compiler barrier which is codegen only. There
is no need to emit an instructions since the XCore provides sequential
consistency.

Original patch by Richard Osborne

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194464 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-12 10:11:26 +00:00
Robert Lytton
c17ea93ed5 XCore target: return error for unsupported alignment
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194463 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-12 10:11:05 +00:00
Robert Lytton
ed0ed946ab XCore target fix bug in emitArrayBound() causing segmentation fault
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192434 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-11 10:27:13 +00:00