search for: miflag

Would adding a flag to MachineInstr::MIFlag do the trick? I'm thinking that fast isel could ensure that a flag (e.g. MIFlag::FastISel) is added to the instructions it creates, then the instruction printer could optionally emit a comment for instructions that have this flag. > -----Original Message----- > From: llvmdev-bounces at c...

...Behalf Of Reed Kotler > Sent: 17 April 2014 16:30 > To: LLVMdev at cs.uiuc.edu > Subject: Re: [LLVMdev] adding comment > > Maybe adding it to CommentFlag would be slightly better. > > On 04/17/2014 02:23 AM, Daniel Sanders wrote: > > Would adding a flag to MachineInstr::MIFlag do the trick? I'm thinking that > fast isel could ensure that a flag (e.g. MIFlag::FastISel) is added to the > instructions it creates, then the instruction printer could optionally emit a > comment for instructions that have this flag. > > > >> -----Original Message----...

...shouldn't be needed. Nuked. > Overall this looks like a great start. However, I would like some other people to review things: > - I don't actually approve lib/CodeGen and lib/Target changes. Somebody else is going to have to think about whether "InsertedNOP" belongs as an MIFlag. The reasoning behind making this an MIFlag was to be able to skip over NOPs in the terminators of a block. For uniform security we want to be able to place NOPs in the terminators, but still need to skip over them when finding the first terminator. > - I'm concerned about seeding the RNG...

Is there a simple way to add a comment in the machine instructions of a basic block? Ideally something that can be used with machine instruction builder. Tia. Reed

...ever read it for anything? Nuke it? Overall this looks like a great start. However, I would like some other people to review things: - I don't actually approve lib/CodeGen and lib/Target changes. Somebody else is going to have to think about whether "InsertedNOP" belongs as an MIFlag. - I'm concerned about seeding the RNG. I'm especially concerned about seeding it in the LTO case, I hadn't thought of that until I saw it in the patch. I'm appreciate if somebody with a security background could ponder that one. - There's also a clang patch which shoul...

Thanks for all the feedback! It seems there is some interest, so I thought I'd try to summarize discussions so far, and provide patches for closer inspection. I'm not sure if patches should end up here or on a different list in this instance, so if I should instead send this to a different list, I'm happy to do so. - Is diversity needed, or are existing protections sufficient? As

...ers to set the FrameSetup flag as well. 2) Like the above, but modify storeRegToStackSlot to return the number of MachineInstr inserted and use that value when marking instructions as FrameSetup. This is more invasive, as it will affect all in tree and out-of-tree backends. 3) Add a MachineInstr::MIFlag parameter to storeRegToStackSlot. The storeRegToStackSlot implementation is responsible for applying this flag to all inserted instructions. This could be defaulted to MachineInstr::NoFlags, to minimise changes to function callers, although that defaulted value would have to be replicated in all Fo...

...other memory operations, and our own instruction scheduler can optimize much better with better alias information. I have created a code which adds marking these spill instructions to the register allocators of llvm. In my implementation spills are marked into spill Machine instructions with MIFlag, adding there a flag bit for spills (currently there is only one flag bit, "FrameSetup" which is only used by x86 backend) My implementation requires just one 9-line function to VirtRegMap class, and a single call to that function in all register allocators. Does this sound reasonable/...

...bove, but modify storeRegToStackSlot to return the number > of > > MachineInstr inserted and use that value when marking instructions as > > FrameSetup. This is more invasive, as it will affect all in tree and > > out-of-tree backends. > > > > 3) Add a MachineInstr::MIFlag parameter to storeRegToStackSlot. The > > storeRegToStackSlot implementation is responsible for applying this flag > to > > all inserted instructions. This could be defaulted to > MachineInstr::NoFlags, > > to minimise changes to function callers, although that defaulted val...