similar to: 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

Hi, Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization? I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern. I'm facing many situations where some patterns are lowered into

The DAG dumping will try to print some of the nodes "inline" (i.e. where they are used) to make the output more readable, so the dump of the DAG may not strictly reflect the node ordering. -Krzysztof On 5/4/2018 8:18 AM, Dominique Torette via llvm-dev wrote: > Here is a last example to illustrate my concern. > > The problem is about the lowering of node t13. > >

Here is a last example to illustrate my concern. The problem is about the lowering of node t13. Initial selection DAG: BB#0 '_start:entry' SelectionDAG has 44 nodes: t11: i16 = Constant<0> t0: ch = EntryToken t3: ch = llvm.clp.set.rspa t0, TargetConstant:i16<392>, Constant:i32<64> t5: ch = llvm.clp.set.rspb t3,

Krzysztof, Thanks for your interest to my questions. In order to clarify the context, here is the C source file of my test case. The 3 builtins initialize some stack pointers. They have to be executed before any other instruction. extern float fdivfaddfmul_a(float a, float b, float c, float d); volatile static float x1,x2,x3,x4; void _start(void) { float res;

Here's our testcase: #include <stdio.h> struct flags { unsigned frog: 1; unsigned foo : 1; unsigned bar : 1; unsigned bat : 1; unsigned baz : 1; unsigned bam : 1; }; int main() { struct flags flags; flags.bar = 1; flags.foo = 1; if (flags.foo == 1) { printf("Pass\n"); return 0; } else {

On 12/21/2016 4:45 PM, Phil Tomson via llvm-dev wrote: > Here's our testcase: > > #include <stdio.h> > > struct flags { > unsigned frog: 1; > unsigned foo : 1; > unsigned bar : 1; > unsigned bat : 1; > unsigned baz : 1; > unsigned bam : 1; > }; > > int main() { > struct flags flags; > flags.bar = 1; >

Hi Krzysztof, Sure, please see below. DAG.dump.() before and after, annotated with what I believe the DAG means. I've spent some time debugging the method but it's proving difficult to determine where the logic is misfiring. Disabling the entire combine causes a lot of failing x86-64 tests - I may have to learn an upstream vector ISA to make progress on this. Thank you >From your

Hello. I'm having problems at instruction selection with my back end with the following basic-block due to a vector add with immediate constant vector (obtained by vectorizing a simple C program doing vector sum map): vector.ph: ; preds = %vector.memcheck50 %.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0

<div> </div><div><div><p>Carry-less multiplication[1] instructions exist (at least optionally) on many architectures: armv8, RISC-V, x86_64, POWER, SPARC, C64x, and possibly more.</p><p>This proposal is to add a <code>llvm.clmul</code> instruction. Or if that is contentious, <code>llvm.experimental.bitmanip.clmul</code> instruction.

Given that this is compiled with -O0, would there a way to skip the Optimization of the Type-legalized selection DAG? It's fine until it optimizes the Type-legalized selection DAG into the Optimized Type-legalized selection DAG. Phil On Thu, Dec 22, 2016 at 10:29 AM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 12/21/2016 4:45 PM, Phil Tomson via llvm-dev wrote: > >

Hello, I've hit an assertion in SelectionDAG where we try to merge 2 loads that have the same operands but their MMO flags differ. One is dereferenceable and one is not. I'm not sure what the underlying issue here is: 1) MDSDNode with the same operands should have the same flags set on their respective MMO. The fact the flags differ when the opcode,types,operands and address-space are

I see we're missing an isel pattern for add producing carry and doing a memory RMW. I'm going to see if adding that helps anything. ~Craig On Mon, Feb 27, 2017 at 8:47 PM, Nirav Davé via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Yes. I'm seeing that as well. Not clear what's going on. > > In any case it looks to be unrelated to the alias analysis so barring

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from

Is there an established way of disabling a DAG combine on a per target basis, where it appears to be detrimental to the generated code? Writing if (!mytarget) in DAGCombiner.cpp works but tends to be erased by git merge and generally doesn't look ideal. Writing the inverse transform in target specific code doesn't work in this instance and in general creates an infinite loop. Guidance

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

int %nlz10(uint %param.x) { %.t3 = shr uint %param.x, ubyte 1 ; <uint> [#uses=1] %.t4 = or uint %.t3, %param.x ; <uint> [#uses=2] %.t7 = shr uint %.t4, ubyte 2 ; <uint> [#uses=1] %.t8 = or uint %.t7, %.t4 ; <uint> [#uses=2] %.t11 = shr uint %.t8, ubyte 4 ; <uint> [#uses=1]

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

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