search for: codegen'ing

...you could create a new entry BB that does nothing but branch to the old entry BB. The old entry BB (now just a regular BB) can then be moved. I'm assuming thus far that you're randomizing the basic block order at the LLVM level (i.e. take LLVM function, randomize order of BBs, and then codegen each BB in order). Another approach, as I see it, would be to change the code generator so that it codegens the BBs in a random order, instead of codegen'ing them in order. The first approach, I think, is a lot easier. Regards, -- John T. > > Thanks > > Tanu > > &g...

...MSA_I16_FMT<0b101010111>; def REP_D: REP_D_ENC, REP_D_DESC; and added in the LLVM program (programmatically, in an LLVM pass) an LLVM IR repeat_x_times intrinsic. To my big surprise (because of the property OperandType = "OPERAND_IMMEDIATE"), the resulting ASM codegen'ed by the instruction selector contains a mov and use a register: mov r1, 32767 // <MCInst #75 MOV_ri // <MCOperand Reg:2> // <MCOperand Imm:32767>> REPEAT_X...

...you could create a new entry BB that does nothing but branch to the old entry BB. The old entry BB (now just a regular BB) can then be moved. I'm assuming thus far that you're randomizing the basic block order at the LLVM level (i.e. take LLVM function, randomize order of BBs, and then codegen each BB in order). Another approach, as I see it, would be to change the code generator so that it codegens the BBs in a random order, instead of codegen'ing them in order. The first approach, I think, is a lot easier. Regards, -- John T. > > Thanks > > Tanu > > >...

...ew entry BB that does nothing but branch to the old > entry BB. The old entry BB (now just a regular BB) can then be moved. > > I'm assuming thus far that you're randomizing the basic block order at > the LLVM level (i.e. take LLVM function, randomize order of BBs, and > then codegen each BB in order). Another approach, as I see it, would be > to change the code generator so that it codegens the BBs in a random > order, instead of codegen'ing them in order. > > The first approach, I think, is a lot easier. > > Regards, > > -- John T. > >> &g...

...ew entry BB that does nothing but branch to the old > entry BB. The old entry BB (now just a regular BB) can then be moved. > > I'm assuming thus far that you're randomizing the basic block order at > the LLVM level (i.e. take LLVM function, randomize order of BBs, and > then codegen each BB in order). Another approach, as I see it, would be > to change the code generator so that it codegens the BBs in a random > order, instead of codegen'ing them in order. > > The first approach, I think, is a lot easier. > > Regards, > > -- John T. > >> &g...

...doesn't come up with DAE or ArgPromo because they > both don > ... they both don't use RAUW because they have to visit each call site to do special stuff anyway. (they're replacing one function with another of a different type, RAUW isn't suitable) I /guess/ we never end up codegen'ing dfsw$main? (I haven't looked) and thus the debug info doesn't describe any function at all. It's possible that there's some other reason we don't end up describing any function at all... In any case if we did have "main" in the debug info describe a function,...

On Mon, 14 Feb 2005, Reid Spencer wrote: > isn't necessarily tied to LLVM. Anyway, lets cross that bridge when we > get there. Sounds good. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/

Hello, In an attempt to randomise the basic blocks in a function, is it possible that I can randomise the entry block as well? And maybe insert some instructions in the pass to call entry block while running the program ? Is it feasible? What does entry block consist of ? Thanks Tanu --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second

...> > > > > > ... they both don't use RAUW because they have to visit each call site to > > do special stuff anyway. (they're replacing one function with another of > a > > different type, RAUW isn't suitable) > > > > I /guess/ we never end up codegen'ing dfsw$main? (I haven't looked) and > > thus the debug info doesn't describe any function at all. It's possible > > that there's some other reason we don't end up describing any function at > > all... > > > > In any case if we did have "m...

On 12/5/18 2:14 PM, Andrew Savonichev wrote: >> On 12/5/18 9:51 AM, Andrew Savonichev via llvm-dev wrote: >>>> Hi, >>>> >>>> I'm trying to get AA results for two pointers, but it seems that AA >>>> cannot look though a memcpy. For example: >>>> >>>> define dso_local spir_func void @fun() { >>>>

...AUW because they have to visit each call > site to > > > > do special stuff anyway. (they're replacing one function with > another of > > > a > > > > different type, RAUW isn't suitable) > > > > > > > > I /guess/ we never end up codegen'ing dfsw$main? (I haven't looked) > and > > > > thus the debug info doesn't describe any function at all. It's > possible > > > > that there's some other reason we don't end up describing any > function at > > > > all... > >...

...interesting implications: it means that it is okay to pass a {i32} struct as i32, and it means passing a _Complex float as two floats is also fine (yay for SROA). However, it means that that lowering a struct with two vectors in it into two vectors would actually break the ABI because the codegen would pass them in XMM regs instead of memory. This is a funny dance which means that the front- end needs to be fully parameterized by the backend to do the lowering. > When generating IR for x86-64, llvm-gcc > sometimes chops by-value structs into pieces, and sometimes passes the >...

On Tue, Oct 7, 2014 at 11:48 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote: > > Hi Peter, > > > > After discovering several bugs in ArgumentPromotion and > > DeadArgumentElimination where llvm::Functions were replaced with similar > > functions (with the same name) to transform their type