search for: isearlyclobber

...I haven't settled on a final version of the operand flags (for registers) >> syntax, but at the moment I'm thinking of something like this: >> - The IsDef flag is implied by the use of the register before the '=', >> unless it's implicit. >> - TiedTo and IsEarlyClobber aren't not serialized, as they are defined by >> the instruction description. (I believe that's true in all cases, but I'm >> not 100% sure). >> - IsUndef, IsImp, IsKill, IsDead, IsInternalRead, IsDebug - keywords like >> 'implicit', 'undef', '...

...nd LDriuh_cdnNotPt is a _conditional_ load, which might or might not Take place based on the outcome of the compare... As such R0 might or might not be defined in this bundle, which obviously changes the liveness update process. My question, do we need another attribute along with isImplicit and isEarlyClobber etc. to designate a conditional def? Furthermore, depending on architectural details we well might have a conditional use as well... and what about the individual (unbundled) def/use? Should this: %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0; ...become this: %R0<def-cond...

...icBlock::dump() as close as possible to the format you use > for serializing. > [...] > > Ideally the new syntax would replace the existing print/dump syntax. The > new syntax will lead to certain missing information when > this information can be inferred (e.g. the TiedTo and IsEarlyClobber > attributes for register operands that I mentioned earlier in this thread), > so maybe we could have some sort of verbose dumping option where > absolutely everything is dumped. I think that the new syntax is less readable than the current format of the "dump" functions, and...

...itional_ load, which might or might not > Take place based on the outcome of the compare... As such R0 might or might > not be defined in this bundle, which obviously changes the liveness update > process. > > My question, do we need another attribute along with isImplicit and > isEarlyClobber etc. to designate a conditional def? Furthermore, depending > on architectural details we well might have a conditional use as well... and > what about the individual (unbundled) def/use? Should this: > > %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0; > > .....

...compute the address RSP + 1 * 0 + 4. I haven't settled on a final version of the operand flags (for registers) syntax, but at the moment I'm thinking of something like this: - The IsDef flag is implied by the use of the register before the '=', unless it's implicit. - TiedTo and IsEarlyClobber aren't not serialized, as they are defined by the instruction description. (I believe that's true in all cases, but I'm not 100% sure). - IsUndef, IsImp, IsKill, IsDead, IsInternalRead, IsDebug - keywords like 'implicit', 'undef', 'kill', 'dead' are used...

...u use > >> for serializing. > >> [...] > >> > >> Ideally the new syntax would replace the existing print/dump syntax. The > >> new syntax will lead to certain missing information when > >> this information can be inferred (e.g. the TiedTo and IsEarlyClobber > >> attributes for register operands that I mentioned earlier in this > thread), > >> so maybe we could have some sort of verbose dumping option where > >> absolutely everything is dumped. > > > > > > I think that the new syntax is less readable than...

...> Take > > place based on the outcome of the compare... As such R0 might or > might > > not be defined in this bundle, which obviously changes the liveness > > update process. > > > > My question, do we need another attribute along with isImplicit and > > isEarlyClobber etc. to designate a conditional def? Furthermore, > > depending on architectural details we well might have a conditional > > use as well... and what about the individual (unbundled) def/use? > Should this: > > > > %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>...

...gt; [...] >>>>> >>>>> Ideally the new syntax would replace the existing print/dump syntax. >>>>> The >>>>> new syntax will lead to certain missing information when >>>>> this information can be inferred (e.g. the TiedTo and IsEarlyClobber >>>>> attributes for register operands that I mentioned earlier in this >>>>> thread), >>>>> so maybe we could have some sort of verbose dumping option where >>>>> absolutely everything is dumped. >>>> >>>> >&g...

Hi,   For a custom target, there is a pass to perform memory dependence analysis, where, i need to get memory pointer for "load instruction". I want to check the pointer alias behavior. I am getting this by considering the memoperands for the load instruction.   For "load instruction", Machine Instruction dumps as below:   vr12<def> = LD_Iri %vr2<kill>, 0;

...tional_ load, which might or might not > Take place based on the outcome of the compare... As such R0 might or might > not be defined in this bundle, which obviously changes the liveness update > process. > > My question, do we need another attribute along with isImplicit and > isEarlyClobber etc. to designate a conditional def? Furthermore, depending > on architectural details we well might have a conditional use as well... and > what about the individual (unbundled) def/use? Should this: > > %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0; > > ...b...

Dave, Thank you for your interest. Please see my replies below. Sorry that my terminology is not as crisp as Andy's, but I think you can see what I mean. Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: dag at cray.com [mailto:dag at cray.com] > Sent: Friday, May 11, 2012 12:14 PM > To: Sergei Larin > Cc:

...aint-list: constraint-list ',' constraint | constraint constraint: '@early' operand | operand '=' operand operand: '$' identifier MachineIntr::addOperand() checks the target instruction description for the constraint when adding register operands and sets IsEarlyClobber if it's present. For a usage example, I've included in the patch the modification to use the constraint for the STREX ARM instruction. Thoughts? Thanks in advance! -Jim -------------- next part -------------- A non-text attachment was scrubbed... Name: early.patch Type: application/...

...ake > > place based on the outcome of the compare... As such R0 might or > might > > not be defined in this bundle, which obviously changes the liveness > > update process. > > > > My question, do we need another attribute along with isImplicit > and > > isEarlyClobber etc. to designate a conditional def? Furthermore, > > depending on architectural details we well might have a conditional > > use as well... and what about the individual (unbundled) def/use? > Should this: > > > > %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>...

...; place based on the outcome of the compare... As such R0 might or >> might >>> not be defined in this bundle, which obviously changes the liveness >>> update process. >>> >>> My question, do we need another attribute along with isImplicit and >>> isEarlyClobber etc. to designate a conditional def? Furthermore, >>> depending on architectural details we well might have a conditional >>> use as well... and what about the individual (unbundled) def/use? >> Should this: >>> >>> %R0<def> = LDriuh_cdnNotPt %P0<...

Hi all, I would like to propose a text-based, human readable format that will be used to serialize the machine level IR. The major goal of this format is to allow LLVM to save the machine level IR after any code generation pass and then to load it again and continue running passes on the machine level IR. The primary use case of this format is to enable easier testing process for the code