search for: recomputeregclass

...possible to replace the virtual register with a GR32 register. It's not impossible to do, but it doesn't come up a lot. When not using sub-registers, the optimization does exist. For example, if you have a VR128 virtual register, but all the instructions using it only require FR32, MRI->recomputeRegClass() will figure it out, and downgrade to FR32. It gets permission to do this because X86RegisterInfo::getLargestLegalSuperClass(VR128) returns FR32. /jakob

...s have to use a 128-bit spill even if we never use anything but the scalar value. Neither option is a good one. > When not using sub-registers, the optimization does exist. For > example, if you have a VR128 virtual register, but all the > instructions using it only require FR32, MRI->recomputeRegClass() will > figure it out, and downgrade to FR32. I don't think this optimization applies because the SSE/AVX instruction defines a vector register but we never use the upper elements. Would adding Fs patterns for these cases, forcing the result register to FR64, help? What does Fs mean anyw...

Jakob Stoklund Olesen <jolesen at apple.com> writes: >> What happens if the result of the above pattern using COPY_TO_REGCLASS >> is spilled? Will we get a 64-bit store or a 128-bit store? > > This behavior isn't affected by the change. FR64 registers are spilled > with 64-bit stores, and VR128 registers are spilled with 128-bit > stores. > > When the

I'm working on generating code for a machine that has a register set kind of like the 68000. For those who don't recall, the 68K has 8 Data registers that can be used for ordinary integer instructions like add, subtract, multiply, shift, etc., and 8 Address registers that can be use for integer addition and a few other things, especially base registers for addressing modes. The Data

On Jul 26, 2012, at 9:43 AM, dag at cray.com wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> As far as I can tell, all sub-register operations involving sub_ss and >> sub_sd can simply be replaced with COPY_TO_REGCLASS: >> >> def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), >> (VMOVSDrr VR128:$src1,

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Akira Hatanaka" <ahatanak at gmail.com> > Sent: Saturday, April 6, 2013 11:56:28 AM > Subject: Re: [LLVMdev] [PATCH]

...al types than > they do today. Also note that we don't require targets to designate a > register class to use for each legal type; in fact, TableGen can compute > the legal type set automatically. Register classes can be inferred from the > selected instructions,MachineRegisterInfo::recomputeRegClass() already > knows how to do that. > [snip] -- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130809/5bdd2a37/attachment.html>

...ch larger set of legal types than they do today. Also note that we don't require targets to designate a register class to use for each legal type; in fact, TableGen can compute the legal type set automatically. Register classes can be inferred from the selected instructions,MachineRegisterInfo::recomputeRegClass() already knows how to do that. With a much larger set of legal types, a separate type legalization phase becomes superfluous. The operation legalizer must be able to do anything the type legalizer can do anyway, so the type legalizer isn't adding any value. The legalizer will work bottom-up...