summaryrefslogtreecommitdiff
path: root/test/CodeGen/XCore
Commit message (Collapse)AuthorAge
* Reduce verbiage of lit.local.cfg filesAlp Toker2014-06-09
| | | | | | 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
* Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-21
| | | | | | | | | 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
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-19
| | | | | | This reverts commit r206704, as expected. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206707 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-19
| | | | | | | | | | | | | | | | | | | | | 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
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)Duncan P. N. Exon Smith2014-04-19
| | | | | | | | | | | 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
* Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)Duncan P. N. Exon Smith2014-04-18
| | | | | | | | | | | | | | | | | | | 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
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)Duncan P. N. Exon Smith2014-04-18
| | | | | | | | | 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
* Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-18
| | | | | | | | | | | | | | 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
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-18
| | | | | | | | | | | 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
* blockfreq: Rewrite BlockFrequencyInfoImplDuncan P. N. Exon Smith2014-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [XCore] Don't create invalid MKMSK instructions inside loadImmediate().Richard Osborne2014-04-14
| | | | | | | | | | | | | | | | | 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
* [XCore] Add support for the "m" inline asm constraint.Richard Osborne2014-03-06
| | | | | | | | | | | | | | 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
* [XCore] Fix call of absolute address.Richard Osborne2014-03-04
| | | | | | | | | | | | | | | 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
* [XCore] Support functions returning more than 4 words.Richard Osborne2014-02-27
| | | | | | | | | | 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
* Revert r202396, r202397.Richard Osborne2014-02-27
| | | | | | 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
* [XCore] Support functions returning more than 4 words.Richard Osborne2014-02-27
| | | | | | | | | | | | | | | | | | 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
* [XCore] Target optimized library function __memcpy_4()Richard Osborne2014-02-27
| | | | | | | | | | | | | | | | 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
* [XCore] Add dag combines for instructions that ignore some input bits.Richard Osborne2014-02-27
| | | | | | | 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
* [XCore] Provide information about known zero bits of resource instructions.Richard Osborne2014-02-27
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202393 91177308-0d34-0410-b5e6-96231b3b80d8
* Use regnum regex in an XCore test case.Andrew Trick2014-02-26
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202315 91177308-0d34-0410-b5e6-96231b3b80d8
* Very temporarily XFAILing a test. Will be fixed shortly.Andrew Trick2014-02-26
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202310 91177308-0d34-0410-b5e6-96231b3b80d8
* [XCore] Add intrinsic for CLRPT (clear port time) instruction.Richard Osborne2014-02-25
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202172 91177308-0d34-0410-b5e6-96231b3b80d8
* [XCore] Add intrinsic for EDU (event disable unconditional) instruction.Richard Osborne2014-02-25
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202171 91177308-0d34-0410-b5e6-96231b3b80d8
* [XCore] Prefer to word align functions.Richard Osborne2014-02-25
| | | | | | | | | | | | | | | | | | | 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
* XCore target: Handle common linkageRobert Lytton2014-02-18
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201563 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target: Fix llvm.eh.return and EH info register handlingRobert Lytton2014-02-18
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201561 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target: fix const section handlingRobert Lytton2014-02-11
| | | | | | | | | | | | 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
* XCore target: Lower ATOMIC_LOAD & ATOMIC_STORERobert Lytton2014-02-11
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201143 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix broken CHECK lines.Benjamin Kramer2014-01-11
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199016 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore Target: correct callee save register spilling when callsUnwindInit is ↵Robert Lytton2014-01-06
| | | | | | true. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198616 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target: Lower EH_RETURNRobert Lytton2014-01-06
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198615 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target: Lower FRAME_TO_ARGS_OFFSETRobert Lytton2014-01-06
| | | | | | | | | 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
* XCore target: Lower RETURNADDRRobert Lytton2014-01-06
| | | | | | 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
* XCore target: Optimise entsp / retsp selectionRobert Lytton2014-01-06
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198612 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target: fix handling of unsized global arrays in large code modelRobert Lytton2014-01-06
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198609 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target: Make handling of large frames not dependent upon an FP.Robert Lytton2013-12-02
| | | | | | | | | | | | 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
* XCore target: fix large code model 'select' indirect address handling.Robert Lytton2013-12-02
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196088 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target: Add large code modelRobert Lytton2013-12-02
| | | | | | | | | | | | | | | | 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
* XCore target: extend tests in preparationRobert Lytton2013-12-02
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196086 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target: Fix eliminateFrameIndex() to handle large framesRobert Lytton2013-12-02
| | | | | | | | 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
* XCore target: Enable frames larger than 65535 to be loweredRobert Lytton2013-12-02
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196084 91177308-0d34-0410-b5e6-96231b3b80d8
* Error if we see an alias to a declaration.Rafael Espindola2013-11-14
| | | | | | | | | | | | | | | 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
* XCore target: implement exception handlingRobert Lytton2013-11-13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194564 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target: fix bug in aligning 'byval i8*' on the stackRobert Lytton2013-11-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194466 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target test for hidden declarationRobert Lytton2013-11-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194465 91177308-0d34-0410-b5e6-96231b3b80d8
* Add XCore support for ATOMIC_FENCE.Robert Lytton2013-11-12
| | | | | | | | | | 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
* XCore target: return error for unsupported alignmentRobert Lytton2013-11-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194463 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target fix bug in emitArrayBound() causing segmentation faultRobert Lytton2013-10-11
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192434 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target does not emit '.hidden' or '.protected' attributesRobert Lytton2013-10-11
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192433 91177308-0d34-0410-b5e6-96231b3b80d8
* XCore target: fix bug in XCoreLowerThreadLocal.cppRobert Lytton2013-10-11
| | | | | | | | | When a ConstantExpr which uses a thread local is part of a PHI node instruction, the insruction that replaces the ConstantExpr must be inserted in the predecessor block, in front of the terminator instruction. If the predecessor block has multiple successors, the edge is first split. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192432 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 06:28:22 +0000