similar to: Lowering Select to Two Predicated Movs

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

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

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

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'm working on project which involves writing a backend for a hypothetical architecture. I am currently trying to figure out the best way to translate for loops to use a specialized "loop" instruction the architecture supports. The instruction is similar X86's loop instruction, where a register is automatically decremented and the condition is automatically checked to see if

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 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

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

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,

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.

Hi Dilan, On 31 May 2016 at 15:34, Dilan Manatunga via llvm-dev <llvm-dev at lists.llvm.org> wrote: > What is the reason for the exclusion of sdiv from the operations considered > valid for execution in a truncated format. A 16-bit division of INT16_MIN by -1 is undefined behaviour but the original ext/trunc version is well-defined as 0. Cheers. Tim.

Things like this in `lib/Target/ARM/ARMExpandPseudoInsts.cpp` FunctionPass *llvm::createARMExpandPseudoPass() { > return new ARMExpandPseudo(); > } And other functions have basically the same style. What's the point of doing it this way instead of just calling `new ARMExpandPseudo` in any place that you would have called this function? -- Ahmed Samara M.S. Computer Engineering

Hi I'm working on a POC adding Windows Phone (ARM) support to the ARM backend. I've encountered the following problem. Microsoft's COFF linker/loader supports a single relocation type ( IMAGE_REL_ARM_MOV32T) on continuous movw/movt Thumb2 instructions opposed to ELF and Mach-O which support relocation per instruction (one for movw and movt). I need to make sure that in case of

Hi, I'm trying to add a new intrinsic to the ARM backend. The intrinsic should a custom comparison. To do so, I started with first defining the intrinsic in llvm/include/llvm/IR/intrinsicsARM.td: def int_foo_cmp : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], []>; The second step I did is adding a new pseudo instruction matching that intrinsic in lib/Target/ARM/ARMInstInfo.td:

> Slightly OT question here, but I have a friend who needs to watch the Rails > intro movs, but is on Linux and has no way of using an actual Quicktime > player. VLC? I assumed everyone used that anyway. http://www.videolan.org/vlc/

On using builtin functions we have to move the input to registers $0 and $1, if one of the input value is an immediate, we fail to propagate the immediate: ... mov u32 $r477 0x00000003 (0) ... mov u32 $r0 %r473 (0) mov u32 $r1 $r477 (0) call abs BUILTIN:0 (0) mov u32 %r495 $r1 (0) ... With this patch the immediate is propagated, potentially causing the first MOV to be superfluous, which we'd

On using builtin functions we have to move the input to registers $0 and $1, if one of the input value is an immediate, we fail to propagate the immediate: ... mov u32 $r477 0x00000003 (0) ... mov u32 $r0 %r473 (0) mov u32 $r1 $r477 (0) call abs BUILTIN:0 (0) mov u32 %r495 $r1 (0) ... With this patch the immediate is propagated, potentially causing the first MOV to be superfluous, which we'd

On 16 January 2018 at 20:40, Ahmed Samara via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Things like this in `lib/Target/ARM/ARMExpandPseudoInsts.cpp` > >> FunctionPass *llvm::createARMExpandPseudoPass() { >> return new ARMExpandPseudo(); >> } > > And other functions have basically the same style. > > What's the point of doing it this way instead