search for: manatunga

...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 didn't get Krzysztof Parzyszek e-mail in my inbox, but > thanks for the fact I can override the getSetCCResultType. Didn't even > think of that. > > -Dilan > > On Wed, Jul 19, 2017 at 7:28 PM Dilan Manatunga &lt...

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, > > > > 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 Regi...

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

...calculation, and the branch). Right now, I thought of using the loop pass to somehow mark the instructions that should be lowered to a loop instruction, and translating them in the selection phase, but I'm not entirely sure how to do that or if that is even the right strategy. Thanks, -Dilan Manatunga -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/43e5524a/attachment.html>

...%conv1 %conv2 = trunc i32 %div to i16 * Assume %0 and %1 are registers created from simple 16-bit loads. We cannot reduce the sequence to: %div = sdiv i16 %0 %1 What is the reason for the exclusion of sdiv from the operations considered valid for execution in a truncated format. Thanks, -Dilan Manatunga -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160531/2d3ea4b6/attachment.html>

...s 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 somewhat confused though. > > MOVCCr gets expanded in the ARMExpandPseudoInsts pass, and it still > > seems only a case of one instruction replacing the other. > > The output of MOVCCr is tied to the "false"...

...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 at 11:20 AM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 7/7/2017 11:12 AM, Dilan Manatunga via llvm-dev wrote: > > 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...

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

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.

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,

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

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