search for: matarazzo

...end of last year. Some time ago. Does your reply intimate it's fixed on trunk? That would be great. (I don't sync too often to avoid churn with my TD.) Joe On Fri, May 31, 2013 at 4:21 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On May 31, 2013, at 4:07 PM, Joe Matarazzo <joe.matarazzo at gmail.com> > wrote: > > > The register coalescer treats virtual super register classes -- a > sequential register range composed of multiple hardware registers -- as a > register with sub registers. When making coalescing decisions it thinks > that the v...

On May 31, 2013, at 4:59 PM, Joe Matarazzo <joe.matarazzo at gmail.com> wrote: > I think the last time I pulled from trunk was probably end of last year. Some time ago. Does your reply intimate it's fixed on trunk? Yes, it’s been fixed recently. /jakob

On May 31, 2013, at 4:07 PM, Joe Matarazzo <joe.matarazzo at gmail.com> wrote: > The register coalescer treats virtual super register classes -- a sequential register range composed of multiple hardware registers -- as a register with sub registers. When making coalescing decisions it thinks that the virtual super reg interferes w...

The register coalescer treats virtual super register classes -- a sequential register range composed of multiple hardware registers -- as a register with sub registers. When making coalescing decisions it thinks that the virtual super reg interferes with sub reg instances, even though in reality they shouldn't conflict. That is, they are individual registers and would be better compared as

...STM would be similar, but the registers are physically enumerated, which is different from these virtual super reg frames I'm trying to construct. Thanks, Joe On Fri, May 31, 2013 at 5:00 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On May 31, 2013, at 4:59 PM, Joe Matarazzo <joe.matarazzo at gmail.com> > wrote: > > > I think the last time I pulled from trunk was probably end of last year. > Some time ago. Does your reply intimate it's fixed on trunk? > > Yes, it’s been fixed recently. > > /jakob > > -------------- next part -...

Jakob, I think this exactly what's happening. I debugged the resolveReferences for the ADD down into the resolve of TSFlags. It calls VarInit::getFieldInit for the "Val" field of "foo". The code is: Init *VarInit::getFieldInit(Record &R, const RecordVal *RV, const std::string &FieldName) const { if (isa<RecordRecTy>(getType()))

Need some guidance about the right way to model this -- how would you model a backend with a handful of read-only physical registers that are passed as arguments to a function? I was emitting copyFromReg nodes in the LowerFormalArgument() routine, but then the register allocator and coalescer are resisting coalescing the COPY MI's for various reasons - for example, the read-only register class

On Fri, Feb 01, 2013 at 04:58:29PM -0800, Joe Matarazzo wrote: > Is it possible to use this operand class in an instruction that has a > pattern defined? If so, can you write it with anything besides a > ComplexPattern in the instruction's pattern DAG, to set it to a value? > Can you refer to it at all? Or would it be added to the Machin...

Is it possible to define lookup tables as a list in tablegen, to map one value to another? Here's the template I was working on: ========================================= class LookupTable { list<int> mapping = [0, 8, 16, 24, 32]; } def LUT : LookupTable; class MyRegister<name, index> : Register<name> { let HWEncoding = LUT.mapping[index]; int otherVal = index;

Is it possible to use this operand class in an instruction that has a pattern defined? If so, can you write it with anything besides a ComplexPattern in the instruction's pattern DAG, to set it to a value? Can you refer to it at all? Or would it be added to the MachineInstr with the default value such that you could modify it later in the backend? If there is a non-ComplexPattern way to write

This code lives in DAGCombiner.cpp: ------------- // Turn 'store float 1.0, Ptr' -> 'store int 0x12345678, Ptr' if (ConstantFPSDNode *CFP = dyn_cast<ConstantFPSDNode>(Value)) { // NOTE: If the original store is volatile, this transform must not increase // the number of stores. For example, on x86-32 an f64 can be stored in one // processor operation but

Hi Joe, Le 11/05/2012 02:13, Joe Matarazzo a écrit : > I've been unable to come up with the TableGen recipe to match a > negated operand. My target asm syntax allows the following transform: > > FNEG r8, r5 > MUL r6, r8, r9 > > to > > MUL r6, -r5, r9 > > Is there a Pattern<> syntax t...

I've been unable to come up with the TableGen recipe to match a negated operand. My target asm syntax allows the following transform: FNEG r8, r5 MUL r6, r8, r9 to MUL r6, -r5, r9 Is there a Pattern<> syntax that would allow matching *any* opcode (or even some subset), not just MUL, with a FNEG'd operand? I expect I can define a PatFrag: def fneg_su : PatFrag<(ops

I'm writing a backend using a mid-October svn snapshot of LLVM. I'm having a hard time figuring out the relationship between my XXXAsmPrinter and MCAsmStreamer. Can someone explain what each is responsible for? Looking at the existing targets, the XXXAsmPrinter implementations seem to implement both the legacy "create a .s file" behavior, using printInstruction/printOperand/etc

In my target, I have setOperationAction(ISD::FSUB, MVT::v4f32, Expand); This produces the desired effect in LegalizeDAG, replacing the FSUB with FADD + FNEG. However, when the vector legalizer runs, it thinks the Expand legalize action means to unroll the vector. This isn't necessary and not what I wanted. Is there a way to get one and not the other? I don't want the unroll aspect of

It seems like this code should work with Tablegen, but it generates the error: "error:Invalid TSFlags bit in ADD" Here's the code: =================================== include "llvm/Target/Target.td" def MyInstrInfo : InstrInfo; def MyTarget : Target { // Information about the instructions... let InstructionSet = MyInstrInfo; } def r1 :