[llvm-commits] [PATCH] Add Pattern ID Information

[Villmow, Micah]

> -----Original Message-----
> From: Chris Lattner [mailto:clattner at apple.com]
> Sent: Friday, August 05, 2011 5:30 PM
> To: Jakob Stoklund Olesen
> Cc: Villmow, Micah; Commit Messages and Patches for LLVM
> Subject: Re: [llvm-commits] [PATCH] Add Pattern ID Information
> 
> 
> On Aug 5, 2011, at 4:42 PM, Jakob Stoklund Olesen wrote:
> 
> >
> > On Aug 5, 2011, at 4:28 PM, Villmow, Micah wrote:
> >
> >>> You would be better off using an immediate operand to encode your
> extra
> >>> semantics.
> >> [Villmow, Micah] That is not really feasible to add an extra operand
> to
> >> hundreds of instructions when there is already a location that store
> the
> >> 15 bits of information that is needed(8 in flags, 7 in
> AsmPrinterFlags).
> >
> > You are of course free to do whatever you want in your own tree. I am
> simply trying to steer you in a direction that will cause you less
> grief when merging with trunk.
> 
> Also, your argument is basically "we are knowingly do something that is
> documented as a bad idea, because it is easier than fixing our code to
> do the right thing".  I'm not going to do it, but this makes me want to
> go rip out asmprinter flags - it doesn't make me inclined to extend
> them.
> 
[Villmow, Micah] I'm not saying extend AsmPrinterFlags, I'm saying remove it and use the 
space that it was reserving to extend the 'Flags' field to 16 bits. I don't see this as the
wrong approach as this is instruction information, not a new operand. I don't see a valid reason
why I need to change my instructions by an extra operand just to work around an artificial 
limitation in LLVM. Having per instruction storage space is required to handle instructions
that require information to be allocated dynamically and not at tablegen compile time.
> -Chris