similar to: [LLVMdev] Introducing a branch optimization and prediction pass

Displaying 20 results from an estimated 9000 matches similar to: "[LLVMdev] Introducing a branch optimization and prediction pass"

2008 Mar 31
0
[LLVMdev] Introducing a branch optimization and prediction pass
On Mar 29, 2008, at 6:02 AM, Török Edwin wrote: > Hi, > > I would like to transform unpredictable conditional branches with a > small body into cmov instructions to reduce branch miss penalty. > LLVM generates cmov/setcc instructions when SelectInst is used. The > idea > is to transform regular branches into selects, when that is possible > and > profitable. LLVM
2008 Mar 31
2
[LLVMdev] Introducing a branch optimization and prediction pass
Evan Cheng wrote: > On Mar 29, 2008, at 6:02 AM, Török Edwin wrote: > > >> Hi, >> >> I would like to transform unpredictable conditional branches with a >> small body into cmov instructions to reduce branch miss penalty. >> LLVM generates cmov/setcc instructions when SelectInst is used. The >> idea >> is to transform regular branches into
2008 Mar 31
0
[LLVMdev] Introducing a branch optimization and prediction pass
On Mar 31, 2008, at 7:01 AM, Török Edwin wrote: > Evan Cheng wrote: >> On Mar 29, 2008, at 6:02 AM, Török Edwin wrote: >> >> >>> Hi, >>> >>> I would like to transform unpredictable conditional branches with a >>> small body into cmov instructions to reduce branch miss penalty. >>> LLVM generates cmov/setcc instructions when
2013 Feb 18
0
[LLVMdev] splitting a branch within a pseudo
This is the old MIPS I code that sort of does what I need to do. This seems really involved to do such a simple thing. Maybe there are now helper classes for this or some better example I can look at. I suppose I can mimick this if people say this just the correct way to do this in LLVM. static MachineBasicBlock* ExpandCondMov(MachineInstr *MI, MachineBasicBlock *BB,
2013 Feb 18
1
[LLVMdev] splitting a branch within a pseudo
Some stuff did not get pasted in properly. static MachineBasicBlock* ExpandCondMov(MachineInstr *MI, MachineBasicBlock *BB, DebugLoc dl, const MipsSubtarget *Subtarget, const TargetInstrInfo *TII, bool isFPCmp, unsigned Opc) { //
2019 Sep 14
2
Side-channel resistant values
Hi Chandler, I feel like this conversation has come full circle. So to ask again: how does one force CMOV to be emitted? You suggested “__builtin_unpredictable()” but that gets lost in various optimization passes. Given other architectures have CMOV like instructions, and given the usefulness of the instruction for performance tuning, it seems like a direct intrinsic would be best. What am I
2013 Feb 17
4
[LLVMdev] splitting a branch within a pseudo
After discussions last night, I'm leaning towards going legit with all my pseudo expansions in Mips 16. Some I think I can clearly do by just putting in the proper side effects of implicit registers (T8 the condition code register as used by mips 16). But I'm still left with some pseudos that have jmp .+4 type instructions in them. The original Mips port was to Mips I and Mips I,
2019 Sep 13
3
Side-channel resistant values
> On Sep 13, 2019, at 10:45 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Fri, Sep 13, 2019 at 1:33 AM David Zarzycki via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi Chandler, > > The data-invariant feature sounds great but what about the general case? When performance tuning code, people sometimes need
2019 Sep 14
2
Side-channel resistant values
I’m struggling to find cases where __builtin_unpredictable() works at all. Even if we ignore cmp/br into switch conversion, it still doesn’t work: int test_cmov(int left, int right, int *alt) { return __builtin_unpredictable(left < right) ? *alt : 999; } Should generate: test_cmov: movl $999, %eax cmpl %esi, %edi cmovll (%rdx), %eax retq But currently generates: test_cmov: movl $999,
2017 Jul 21
4
Issue with DAG legalization of brcond, setcc, xor
But isn't kinda silly that we transform to xor and then we transform it back. What is the advantage in doing so? Also, since we do that method, I now have to introduce setcc patterns for i1 values, instead of being able to just use logical pattern operators like not. -Dilan On Fri, Jul 21, 2017 at 11:00 AM Dilan Manatunga <manatunga at gmail.com> wrote: > For some reason I
2017 Jul 20
3
Issue with DAG legalization of brcond, setcc, xor
Hi, I am having some issues with how some of the instructions are being legalized. So this is my intial basic block. The area of concern is the last three instructions. I will pick and choose debug output to keep this small. SelectionDAG has 36 nodes: t0: ch = EntryToken t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507 t2: i32,ch = CopyFromReg t0, Register:i32 %vreg17
2014 Jul 01
2
[LLVMdev] Probable error in InstCombine
I've found what appears to be a bug in instcombine. Specifically, the transformation of -(X/C) to X/(-C) is invalid if C == INT_MIN. Specifically, if I have > define i32 @foo(i32 %x) #0 { > entry: > %div = sdiv i32 %x, -2147483648 > %sub = sub nsw i32 0, %div > ret i32 %sub > } then opt -instcombine will produce > define i32 @foo(i32 %x) #0 { > entry: > %sub
2009 Mar 22
3
[LLVMdev] Flags/ConditionCode Model is broken
Hi all, I've spent the day trying to understand setcc/select_cc intricacies, and I thought I should mention that so far as I can tell, the modeling of CPU flags, condition codes and therefore conditional instructions seems pretty broken. On the one hand there are the SDNPInFlag/SDNPOutFlag node properties which allow you to mark an instruction as using or def-ing the CPU flags
2014 Jul 05
2
[LLVMdev] LLVM commit 410f38e01597120b41e406ec1cea69127463f9e5
Hi, I'm working on a target which have a variable size for CC (the same size as the arguments). As a result getSetCCResultType, return a variable size. In this commit, at the line DAG.getSExtOrTrunc(SetCC, DL, SelectVT), on my target, you end up generating the Node you are replacing, and so creating a loop in the DAG, which give a whole new meaning to the A in the acronym. Subsequent code
2013 Mar 05
4
[LLVMdev] Vector splitting vs widening
Hello, Working on my (currently out-of-tree) BG/Q PPC enhancements, I've run into the following problem with vector type legalization. Here's a quick example: Scalarize node result 0: 0x2348420: v1f32 = extract_subvector 0x23434a0, 0x2348320 [ID=0] Scalarize node result 0: 0x2348220: v1f32 = extract_subvector 0x23434a0, 0x23466e0 [ID=0] Split node result: 0x23469e0: v4f32 =
2008 Dec 12
4
[LLVMdev] i1 promotion issue (again)
Background: The Cell SPU does not have condition registers in the normal sense. It fits the "zero or negative one" model, preferably with an i32 register, which is what getSetCCResultType() will return. Problem: LegalizeTypes promotes i1 to i8 via an i32 setcc, i.e., the generated type legalization is: (i8:truncate (i32:setcc i32:lhs, i32:rhs, ch:cond)) How do I keep
2014 Jul 08
2
[LLVMdev] LLVM commit 410f38e01597120b41e406ec1cea69127463f9e5
On 07/08/2014 03:20 PM, Matt Arsenault wrote: > Alternatively maybe this should only be done if the setcc type is the > same as the sext result? I think we should actually do this. If you need to convert the setcc result after, you aren't really gaining anything by doing this transformation -------------- next part -------------- An HTML attachment was scrubbed... URL:
2014 Jul 08
2
[LLVMdev] LLVM commit 410f38e01597120b41e406ec1cea69127463f9e5
OK from what I understand, the DAG.getSExtOrTrunc(SetCC, DL, SelectVT) is unecessary and the SelectVT is nto the right type (as it is called with incorrect parameter). Here is a patch so it won't generate a loop. I ran make check and it doesn't look like anything is broken. 2014-07-07 11:36 GMT-07:00 Matt Arsenault <arsenm2 at gmail.com>: > > On Jul 5, 2014, at 7:14 PM,
2009 Mar 22
0
[LLVMdev] Implementing select_cc without cmov
someguy wrote: > Hi All, > > I need to implement select_cc as a "cmp; mov rX,1; brcond cnd, END; > mov rX,0; END:" sequence. > > Chris mentioned that the PPC code (as well as the x86 SSE code) does > this, but I can't seem to find it. > > What I really need to kmow is how to insert the branch/label pair at > instruction selection phase. > > Anyone
2014 Jul 08
2
[LLVMdev] LLVM commit 410f38e01597120b41e406ec1cea69127463f9e5
2014-07-08 12:11 GMT-07:00 Matt Arsenault <Matthew.Arsenault at amd.com>: > On 07/07/2014 09:47 PM, deadal nix wrote: > > OK from what I understand, the DAG.getSExtOrTrunc(SetCC, DL, SelectVT) > is unecessary and the SelectVT is nto the right type (as it is called with > incorrect parameter). > > Here is a patch so it won't generate a loop. I ran make check and