search for: mcizat

...kes sense with AVX > (so it is "legal"). You just have to emit the register name as "xmm" rather > than "ymm." Why write an additional complicated pattern for this case? Please don't use asmprinter modifiers. I'm trying to remove them as part of the MCization code. Please use the SUBREG machine instr and (subreg) tblgen node as appropriate. -Chris

...for us to examine to further the discussion. What's being debated here seems like an optimization for compile time. I'm certainly in favor of that, but I can think of a ton of things I'd rather that we work on first that matter for correctness. For example, we're lacking proper EH, MCization of ARM attributes, accurate scheduling, etc. deep

On 28 September 2010 19:54, Bob Wilson <bob.wilson at apple.com> wrote: > Really?  ARM's specifications of these types show them as structs, and as my example demonstrates, GCC's "implementation choice" allows code that is incompatible with ARM's compiler.  I guess you are saying that is OK. OK in the sense that it works, yes. OK in the sense that I welcome it, then

On Tuesday 24 November 2009 14:12, Anton Korobeynikov wrote: > Hello, David > > > How does ${dst:subreg32} work? > > This is just modifier provided to asmprinting code. Here, it seems, 16 > bit register is passed to asmprinter, but it sees modifier and grabs > 32-bit superreg. > > > Can one do the same for sources? > > Yes, this is just modifier for printing,

Hello, David > How does ${dst:subreg32} work? This is just modifier provided to asmprinting code. Here, it seems, 16 bit register is passed to asmprinter, but it sees modifier and grabs 32-bit superreg. > Can one do the same for sources? Yes, this is just modifier for printing, nothing more... > Is it preferable to use the source modifier or write an EXTRACT_SUBREG > pattern