similar to: [LLVMdev] Live code elimination problem in code generation

On Oct 14, 2011, at 9:04 PM, Hae-woo Park wrote: > I've met a problem that eliminates a live code in code generation phase. > > The initially generated code is shown as follows (as a pseudo code): > ( Before pseudo-code expansion. ) > > ---------- > loop: > : > : > set P0 <- xxx ( P0: a physical register for a parameter of function F ) > set P1

Hello :) I am looking around __builtin_expect() directive for optimization. ( http://llvm.org/docs/BranchWeightMetadata.html ) Since it is not included in v2.9, I am searching about it on svn trunk. I found that the lowering phase generates branch-weight metadata node for that directive. However, I can't find any code related to the metadata even in the branch transformation code. IMHO, in

Eli, Thanks for the tips. I've been able to get something working using a custom instruction inserter, however, I'm still having the problem of linking together the setcc and the select_cc commands. I want to turn the setcc into a comparison and use the results in the select_cc register. However, the comparison information is in the select_cc instruction and the result of the comparison

On Thu, Sep 11, 2008 at 6:14 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I am attempting to lower the selectCC instruction to the instruction set of > the backend I'm working on and I cannot seem to find a way to correctly > implement this instruction. I know how this instruction should get > implemented; I just have yet to find a way to do it. I want the select_cc

Can someone explain how the condition code is passed from the MBlazeTargetLowering::LowerSELECT_CC to MBlazeTargetLowering::EmitCustomSelect custom inserter? In LowerSELECT_CC the condition code is never accessed (Op.GetOperand(4)) and I don't see how it ends up getting correctly passed to the MBlazeTargetLowering::EmitCustomSelect. > SDValue

On Wed, 4 Oct 2006, Roman Levenstein wrote: >> You can add the line >> setOperationAction(ISD::SELECT, MVT::i32, Expand); >> to the constructor of you TargetLowering class. See the current >> backend for an example. > > I actually tried it first. But then if, I remember correctly, SELECT > nodes were expanded into something using SELECT_CC, which is also not >

I am trying to add support for select_cc. In ARM it can be implemented with: mov $dst, $falseVal cmp $a, $b moveq $dst, $trueVal My current strategy is to expand select_cc in two ARM nodes: ARM::SELECT and ARM::CMP. The two nodes would be connected by a flag edge. ARM::CMP would then expand to "cmp $a, $b". This instruction has no results. It only alters the CPSR (current program

Hello, I'd like to write some unit tests which verifies SELECT_CC and BR_CC lowering for ARM target, but I'm almost completely unfamiliar with llvm/Target. How can I get this nodes in DAG? Thanks. -- Kind regards, Dmitry Borisenkov -------------- next part -------------- An HTML attachment was scrubbed... URL:

> On Wed, 4 Oct 2006, Roman Levenstein wrote: > >> You can add the line > >> setOperationAction(ISD::SELECT, MVT::i32, Expand); > >> to the constructor of you TargetLowering class. See the current > >> backend for an example. > > > > I actually tried it first. But then if, I remember correctly, > SELECT > > nodes were expanded into

What guarantees, if any, does the scheduler make when two selection nodes are linked by a Flag type? Can I expect the machine instructions that are selected from the two nodes to be scheduled consecutively? I'm trying to implement code generation for SELECT_CC nodes in a back end that I'm working on. The compare operations on the architecture communicate via bits in a global status

I am attempting to lower the selectCC instruction to the instruction set of the backend I'm working on and I cannot seem to find a way to correctly implement this instruction. I know how this instruction should get implemented; I just have yet to find a way to do it. I want the select_cc instruction to be lowered into a comparison followed by a conditional move. I've attempted to use a

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 have an example of this?

On Tue, Mar 15, 2016 at 2:21 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 3/15/2016 4:16 PM, Rail Shafigulin via llvm-dev wrote: > >> Below is the output of llc with a -debug-only=isel. As you could see the >> output type for load, store, and add changes from v4i32 to i32 during >> legalization. How can I preserve the output type to

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

Hi Chris, Thank you very much for your answer! It helps me to move in the right direction. When you explain it, it sounds rather easy. But I still have some tricky issues. This is either because I'm not so familiar with LLVM or because it is a bit underestimated how much LLVM legalizer/expander relay on expandable types to be integers (see my explanations below). --- Chris Lattner <sabre

Hi Rafael, Thanks for the answers. > > 1) My target (embedded processor, which is a "not so direct" > successor > > of Z80 family of processors) does not support SELECT, so I was > looking > > for a workaround. > > > > First I was thinking about expanding it into conditional flow with > > branching, but then I have found that there exists a

I attempt to optimize the use of the ‘CMP’ instruction on my architecture by removing the instruction instances where the Status Register already had the correct status flags. The cmp instruction in my architecture is the typical one that compares two registers, or a register with an immediate, and sets the Status Flags accordingly. I implemented my ‘cmp’ instruction in LLVM by custom lowering

Hello LLVM Developers, I am working on an architecture which have one bit shift operation if barrel shiftier hardware is not present in such cases some DAGCombine optimizations reduces performance of certain benchmarks upto 5% for example consider follwing optimization: fold (select_cc seteq (and x, y), 0, 0, A) -> (and (shr (shl x)) A) Here it introduce 2 shift operations and when barrel

Hi Eli, Thank you very much for your response. In fact, I had already tried the X86 approach before, i.e explicitly using the status register. This is the approach that appeals more to me. I left it parked because it also produced some problems (but I left it commented out). So I have now re-lived the code, and it works fine in most cases, but there’s a particular case that causes LLVM to stop

Hi Eli, Thanks again for your reply. I am unsure about implementing the getCrossCopyRegClass for my target. My target does not support or allow moves to and from the SR. The SR exists because it has implicit involvement in some instructions, but it is opaque to the assembler and to the user as a register. I mean, there are no instructions to directly move or read it, or even access it directly.