similar to: Lowering For Loops to use architecture "loop" instruction

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

Ohh, that makes sense. And is the reason the first instruction doesn't get deleted because the ExpandPseudoInstructions pass occurs after Register Allocation and machine dead code elimination? -Dilan On Fri, Jul 7, 2017 at 12:37 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 7/7/2017 12:10 PM, Dilan Manatunga wrote: > > My bad for not looking further. I'm still

My bad for not looking further. I'm still somewhat confused though. MOVCCr gets expanded in the ARMExpandPseudoInsts pass, and it still seems only a case of one instruction replacing the other. My worry of emitting two instructions, is that a dead code pass will eliminate the first instruction cause it thinks the second instruction is defining the same register. -Dilan On Fri, Jul 7, 2017

Thanks that clears things up. So if I want to mess around with how schedules are generated, looking at the MachineScheduler pass is the best place now? -Dilan On Mon, Jul 31, 2017 at 3:24 PM Matthias Braun <mbraun at apple.com> wrote: > > > On Jul 31, 2017, at 2:51 PM, Dilan Manatunga via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi, > >

Hi, I was wondering what would be the best way to lower a select operation two predicated movs. I looked through the ARM, MIPS, and NVPTX backends and they all seem to lower a select to some sort of conditional move or native select operation. Ex. select t3, cond, t2, t1 Becomes cond mov t3, t2 !cond mov t3, t1 -Dilan -------------- next part -------------- An HTML attachment was scrubbed...

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

I was looking through the InstCombine pass, and I was wondering why signed division is not considered a valid operation to combine in the canEvaluateTruncated function. This means, given the following code: %conv = sext i16 %0 to i32 %conv1 = sext i16 %1 to i32 %div = sdiv i32 %conv, %conv1 %conv2 = trunc i32 %div to i16 * Assume %0 and %1 are registers created from simple 16-bit loads. We

On 31 May 2016 at 16:02, Dilan Manatunga <manatunga at gmail.com> wrote: > Just to verify, a 16-bit divion of INT16_MIN by -1 results in INT16_MIN > again? No, "sdiv i16 -32768, -1" is undefined behaviour. The version with an "sext" and "trunc" avoids the undefined behaviour and does return -32768. > If the issue only occurs in this case, why

Hi, I was looking into how SelectionDAG scheduling is done in LLVM for different backends, and I noticed that for the X86 backend, even though it sets scheduling preferences of ILP or RegisterPressure depending on architecture, in the end, it ends up using source scheduling. I realized this is because it overrides enableMachineScheduler to return true. Is there any specific reasons why it was

Hi, I am working on a custom backend, and I am trying to figure out how to deal with some branching inefficiencies in my output code, and the best way to fix it. So, let's say I am compiling a small function that takes the sum of an array. int loop(int* array, int n) { int ret = 0; for (int i = 0; i < n; i++) { ret += array[i]; } return ret; } The problem I am having is that

On 31 May 2016 at 15:42, Tim Northover <t.p.northover at gmail.com> wrote: > A 16-bit division of INT16_MIN by -1 is undefined behaviour but the > original ext/trunc version is well-defined as 0. Sorry, INT16_MIN again actually. The main point still stands though, I think. Tim.

LLVM, What is the status of the InductionVariable "semi-pass"? I have tested it out on spec benchmarks, and while it does correctly identify some of the variables, it fails to recognize most. Typically the following scenario arises a_loop: ... %tmp.19 = load int* %bsLive %tmp.20 = add int %tmp.19, -8 store int %tmp.20, int* %bsLive %tmp.5 = setgt int %tmp.20, 0 br bool %tmp.5, label

Just to verify, a 16-bit divion of INT16_MIN by -1 results in INT16_MIN again? If the issue only occurs in this case, why aren't there checks to see if we can simplify sdiv in cases where we know that numerator is not INT16_MIN or the denominator is not -1. For example, we could simplify divides involving one operand constants. Is it because this case is most likely rare? -Dilan On Tue,

Note: Question is written after describing what I have coded. Hello LLVMDevs, I am trying to impliment floating point comparsion for an architecture which supports following type of floating point comparision if FPU is available: fcmp.un --> true if one of the operand is NaN fcmp.lt --> ordered less than, if any input NaN then return false fcmp.eq --> ordered equal, if any input NaN

On Thu, Mar 9, 2017 at 9:35 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 02/25/2017 03:06 AM, vivek pandya via llvm-dev wrote: > > Note: Question is written after describing what I have coded. > > Hello LLVMDevs, > > I am trying to impliment floating point comparsion for an architecture > which > supports following type of floating point comparision if FPU

On 03/14/2017 07:16 AM, vivek pandya wrote: > Hello Hal, > setCondCodeAction(expand) for un ordered comparison generates > semantically wrong code for me for example SETUNE gets converted to > SETOE that causes infinite loops. Can you please explain what is happening? It sounds like a bug we should fix. > > What is ideal place where I can convert unordered comparison to un

On Sep 9, 2010, at 12:59 PM, Borja Ferrer wrote: > Hello, i've noticed a new possible missed optimization while testing more trivial code. > This time it's not a with a xor but with a multiplication instruction and the example is little bit more involved. > > C code: > > typedef short t; > t foo(t a, t b) > { > t a4 = a*b; > return a4; > } >

You can tell LLVM that you have "sign extended" setCC results (all ones). Dan On Nov 18, 2008, at 5:33 PM, Eli Friedman wrote: > On Tue, Nov 18, 2008 at 1:56 PM, Villmow, Micah > <Micah.Villmow at amd.com> wrote: >> The IR produces correct results, but my backend does not and the >> only thing >> I can think of is that the IR is treating the

Hello, i've noticed a new possible missed optimization while testing more trivial code. This time it's not a with a xor but with a multiplication instruction and the example is little bit more involved. C code: typedef short t; t foo(t a, t b) { t a4 = a*b; return a4; } argument "a" is passed in R15:R14, argument "b" in R13:R12, the return value is stored in

Hi, I'm trying to build code for very short function and I encounter with a problem (or bug) in DAG selection algotithm. I have a node that was created in Combine(BeforeLegalizeTypes) and should be optimized in Combine(AfterLegalizeTypes). But LegalizeTypes() did not change anything and Combine(AfterLegalizeTypes) was not called. Vector legalization that comes afterwards just scalarized the