similar to: [LLVMdev] [RFC] Add compiler scheduling barriers

Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] [RFC] Add compiler scheduling barriers"

2014 Jun 27
3
[LLVMdev] [RFC] Add compiler scheduling barriers
On 24 June 2014 01:55, Philip Reames <listmail at philipreames.com> wrote: > > On 06/19/2014 09:35 AM, Yi Kong wrote: >> >> Hi all, >> >> I'm currently working on implementing ACLE extensions for ARM. There >> are some memory barrier intrinsics, i.e.__dsb and __isb that require >> the compiler not to reorder instructions around their
2014 Jul 03
2
[LLVMdev] [RFC] Add compiler scheduling barriers
After some internal discussions, we concluded that moving non-memory-access and non-side-effect instructions around memory barrier intrinsics is fine in almost any typical situation. In the rare occasions where reordering is undesirable, the programmer should use inline asm instead. Thus I'm dropping this RFC. Thanks for your comments. -Yi
2018 Sep 16
2
How to add a barrier pseudo instruction?
Hello all, I want to add a custom intrinsic to the LLVM IR which would be lowered into a pseudo instruction since it doesn't correspond to any real instruction defined by the architecture. The speciality of this intrinsic/pseudo instruction that it should behave like a scheduling barrier: every instruction before the intrinsic has to be emitted before the intrinsic, the same goes for all
2018 Sep 18
2
How to add a barrier pseudo instruction?
Hi Tim, Thank you a lot for your reply. So IIUC, optimization passes in opt do not reorder IR instructions, only passes in llc that move MIR instructions around. Is it correct? On the back-end (llc) side, hasSideEffects might prevent some reordering. But I just learn about TargetInstrInfo::isSchedulingBoundary. Can you tell me what are the differences between the two please? Thank you very much
2014 Aug 01
2
[LLVMdev] Recent compile time performance regressions
Hi Chandler, On an x86 system, for ToT LLVM: With "Remove support for LLVM runtime multithreading": 23.8788 With patch reverted: 22.5229 That's around 6% regression. Detailed JSON file is at http://paste.debian.net/113238, http://paste.debian.net/113239 -Yi On 1 August 2014 21:56, Chandler Carruth <chandlerc at google.com> wrote: > > On Fri, Aug 1, 2014 at 1:47 PM,
2016 Apr 15
3
[Sparc] Load address with SETHI
Hi, I'm trying to implement __builtin_setjmp / __builtin_longjmp for Sparc processors. I think I'm very close, but I can't work out how to issue BuildMI-type instructions to load the address of the recovery location (set in setjmp) into a register using the SETHI / OR combination. I can't see any equivalent code anywhere else in Sparc. I imagine this is similar if I try to make a
2017 Aug 21
3
RFC/bikeshedding: Separation of instruction and pattern definitions in LLVM backends
On 21 August 2017 at 11:53, Daniel Sanders <daniel_l_sanders at apple.com> wrote: > One thing to be aware of with this is that (IIRC) tablegen uses the pattern to infer things about the pattern. One example I vaguely remember is that an empty pattern would result in the same effect as hasSideEffects=1 and I think there were others. Thanks for the note - excellent point. Looking at
2014 Aug 01
3
[LLVMdev] Recent compile time performance regressions
On 1 August 2014 21:33, Chandler Carruth <chandlerc at google.com> wrote: >> Note, this patch is actually the smaller culprit, around 209801 there is >> another performance regression, but I have no idea if/where this is coming >> from or if this for some reason is a false positive. > > > I'm having to question the results on this bot. The range of commits
2016 Mar 21
3
New intrinsic property IntrOnlyWrite
On 19.03.2016 16:25, Mehdi Amini wrote: > Hi, > > Can you elaborate what is the impact at the IR level? > If the point is just about how you lower for you target, why are you needing an IR level attribute? You backend if free to specialize the lowering for any intrinsic regardless the IR level attributes. As I explained in my reply to Philip, what I really need is a way to get
2016 Nov 15
2
how to prevent LLVM back-end from reordering instructions at instruction scheduling?
Setting the MI as isTerminator should have the same impact, yes? I'm not sure of the other consequences of this though, if any, have to look into it. Thanks. -Ryan On Tue, Nov 15, 2016 at 5:18 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > You can override TargetInstrInfo::isSchedulingBoundary for that. > > -Krzysztof > > On 11/15/2016 4:13 PM, Ryan
2016 Aug 22
2
Instruction itineraries and fence/barrier instructions
On Mon, Aug 22, 2016 at 11:40 AM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Aug 22, 2016, at 11:20, Phil Tomson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > We improved our instruction itineraries and now we're seeing our > testcases for fence instructions break. > > > > For example, we have this testcase: > >
2016 Mar 19
4
New intrinsic property IntrOnlyWrite
Hi, I'd like to draw your attention to http://reviews.llvm.org/D18291, in which I propose a new intrinsic property for intrinsics that are lowered to instructions that mayStore, but are neither mayLoad nor hasSideEffects. This is relevant for AMDGPU, where we have store instructions that don't operate on pointers. The codegen backend understands these perfectly well as stores, and so
2016 Aug 22
3
Instruction itineraries and fence/barrier instructions
We improved our instruction itineraries and now we're seeing our testcases for fence instructions break. For example, we have this testcase: @write_me = external global i32 @read_me = external global i32 ; Function Attrs: nounwind define i32 @xstg_intrinsic(i32 %foo) #0 { entry: ; CHECK: store r0, r1, 0, 32 ; CHECK-NEXT: fence 2 %foo.addr = alloca i32, align 4 store i32 %foo,
2014 May 16
2
[LLVMdev] Use perf tool for more accurate time measuring on Linux
On 16 May 2014 18:08, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Yi Kong" <kongy.dev at gmail.com> >> To: "Hal Finkel" <hfinkel at anl.gov>, "Renato Golin" <renato.golin at linaro.org>, "Tobias Grosser" <tobias at grosser.es> >> Cc: "LLVM Dev" <llvmdev at
2004 Jun 23
3
[LLVMdev] Linearscan allocator bug?
Chris Lattner wrote: > On Tue, 22 Jun 2004, Vladimir Prus wrote: > > First, I attach two files -- LLVM asm and the asm for my target. The > > problem with assembler is: on line 171 it uses register gr2, which is > > copied from gr6 above, on line 161. The only predecessor of this basic > > block is jump on line 90. The problem is that gr6 is not initialized in > >
2015 Aug 12
2
ARM: Predicated returns considered analyzable?
Doh. I missed the list in my first reply... Here's the replay of the conversation: ----- Renato: On 10 August 2015 at 14:05, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > --> %SP<def,tied1> = t2LDMIA_RET %SP<tied0>, pred:8, pred:%CPSR, > %R7<def>, %PC<def>, %SP<imp-use,undef>, %R7<imp-use,undef>, >
2015 Aug 10
2
ARM: Predicated returns considered analyzable?
Hello, The function ARMBaseInstrInfo::AnalyzeBranch contains the following piece of code: } else if (I->isReturn()) { // Returns can't be analyzed, but we should run cleanup. CantAnalyze = !isPredicated(I); } else { This could lead to cases where for a block that ends with a conditional return, AnalyzeBranch returns false (i.e. analyzed), both TBB and FBB are
2016 Mar 21
3
New intrinsic property IntrOnlyWrite
On 19.03.2016 14:47, Philip Reames wrote: > I'm generally in support of this change. I haven't looked at the patch > yet, but the direction seems worthwhile. > > Note that we already have a writeonly predicate in a few places in the > code (BasicAA being one). If we do introduce the new intrinsic > property, we should refactor all of these places to use the new >
2004 Jun 23
0
[LLVMdev] Linearscan allocator bug?
On Wed, 23 Jun 2004, Vladimir Prus wrote: > Hmm.. this is what I have in td file already: > > let isTerminator = 1 in > def GOTO : Unknown<"goto">; > def IFEQ : Unknown<"if =0 goto">; > def IFNEQ : Unknown<"if <>0 goto">; > ..... > > Should this work? Nope, but try this: let isTerminator = 1 in {
2016 Mar 22
1
New intrinsic property IntrOnlyWrite
> On Mar 21, 2016, at 9:14 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Mar 21, 2016, at 8:58 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote: >> >> On 19.03.2016 16:25, Mehdi Amini wrote: >>> Hi, >>> >>> Can you elaborate what is the impact at the IR level? >>> If the point is just about