search for: fceil

...(ins R600_Reg32:$src, R600_Pred:$p, i32imm:$flags), > !strconcat(opName, " $dst, $src ($p)"), > pattern, > itin >> ; > > And an instruction def: > > def CEIL : R600_1OP < > 0x12, "CEIL", > [(set R600_Reg32:$dst, (fceil R600_Reg32:$src))] >> ; > > Tablegen fails to compile this with an error: "Operand $flag does not > appear in the instruction pattern" > > Is there some way I can have this pattern initialize the $flag operand > to 0? The generally accepted way of achieving this...

...s), > > !strconcat(opName, " $dst, $src ($p)"), > > pattern, > > itin > >> ; > > > > And an instruction def: > > > > def CEIL : R600_1OP < > > 0x12, "CEIL", > > [(set R600_Reg32:$dst, (fceil R600_Reg32:$src))] > >> ; > > > > Tablegen fails to compile this with an error: "Operand $flag does not > > appear in the instruction pattern" > > > > Is there some way I can have this pattern initialize the $flag > operand > > to 0? > &...

...(outs R600_Reg32:$dst), (ins R600_Reg32:$src, R600_Pred:$p, i32imm:$flags), !strconcat(opName, " $dst, $src ($p)"), pattern, itin >; And an instruction def: def CEIL : R600_1OP < 0x12, "CEIL", [(set R600_Reg32:$dst, (fceil R600_Reg32:$src))] >; Tablegen fails to compile this with an error: "Operand $flag does not appear in the instruction pattern" Is there some way I can have this pattern initialize the $flag operand to 0? Thanks, Tom

All, The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on register operands. This is because many target-independent passes are manipulating register operands

...n MO_Register >> MachineOperands >> >> Tom, >> >> The generally accepted way of achieving this is to leave the built-in >> pattern on the instruction empty, and to use def : Pat constructs to >> provide the default values. >> >> def : Pat<(fceil R600_Reg32:$src), (CEIL R600_Reg32:$src, (i32 0))>; >> > [Villmow, Micah] Doing this for every instruction is unrealistic. Not particularly. There are backends already in existence that make heavy use of it. The key is that def : Pat constructs can take advantage of all of the same...

hi all I have a question about implementing a new instruction which does this function f(x) = x + ceilf (x) .x is a single float i have already added the instruction in my backend in the .td file def SUBCEIL_S : FFR<0x11, 0x3, 16, (outs FGR32:$fd), (ins FGR32:$fs), "frac.s\t$fd, $fs", [(set (f32 FGR32:$fd), (fadd (f32 FGR32:$fs ),(f32 (ceilf FGR32:$fs))))] >; it makes

...; > > it makes and install correctly but when i ll try to write code to use this > instruction there is no luck. More details (including the .ll source and *how* exactly things are going wrong) would be useful. Does llc crash? Does it simply not select your code even though there's an fceil in the DAG? Is there no fceil node in the DAG (run llc with "-view-isel-dags")? Assuming the "ceilf" is a typo, my wild stab in the dark would be that you've got code something like: define float @foo(float %in) { %1 = tail call float @ceilf(float %in) ret float %1 }...

...t;-emit-llvm" option (and probably "-S"). Anyway, what I see in the C you posted is that Clang is using constant folding to avoid doing any of the operations you've requested. A better C file test would be: float foo(float d) { return d - ceilf(d); } For me LLVM does use the FCEIL node in that case (it doesn't know what d is so can't optimise your operations away). I'm still a little worried that ceilf isn't declared, but LLVM seems to do the "right" thing anyway. I'm also a little worried that your pattern has fadd, but your C source has a sub...

Hi and thanks for answering llc works fine just does not selecting my instruction i ve uploaded .ll file how can i include this attribute "readonly" so i can see if changes the generated assembly? my code is very simple int main (){ float d, d1 ; d= 12.3; d1 = d - ceilf(d); return 0; } -- View this message in context:

...>> > >> Tom, > >> > >> The generally accepted way of achieving this is to leave the built- > in > >> pattern on the instruction empty, and to use def : Pat constructs to > >> provide the default values. > >> > >> def : Pat<(fceil R600_Reg32:$src), (CEIL R600_Reg32:$src, (i32 0))>; > >> > > [Villmow, Micah] Doing this for every instruction is unrealistic. > > Not particularly. There are backends already in existence that make > heavy use of it. The key is that def : Pat constructs can take >...

...+ case ISD::FP_TO_UINT: + case ISD::FNEG: + case ISD::FABS: + case ISD::FSQRT: + case ISD::FSIN: + case ISD::FCOS: + case ISD::FPOWI: + case ISD::FPOW: + case ISD::FLOG: + case ISD::FLOG2: + case ISD::FLOG10: + case ISD::FEXP: + case ISD::FEXP2: + case ISD::FCEIL: + case ISD::FTRUNC: + case ISD::FRINT: + case ISD::FNEARBYINT: + case ISD::FFLOOR: + switch (TLI.getOperationAction(I->getOpcode(), I->getValueType(0))) { + case TargetLowering::Promote: + Result = PromoteVectorOp(SDValue(Result, 0)).getNode(); + break; +...

...+ case ISD::FP_TO_UINT: + case ISD::FNEG: + case ISD::FABS: + case ISD::FSQRT: + case ISD::FSIN: + case ISD::FCOS: + case ISD::FPOWI: + case ISD::FPOW: + case ISD::FLOG: + case ISD::FLOG2: + case ISD::FLOG10: + case ISD::FEXP: + case ISD::FEXP2: + case ISD::FCEIL: + case ISD::FTRUNC: + case ISD::FRINT: + case ISD::FNEARBYINT: + case ISD::FFLOOR: + switch (TLI.getOperationAction(I->getOpcode(), I->getValueType(0))) { + case TargetLowering::Promote: + Result = PromoteVectorOp(SDValue(Result, 0)).getNode(); + break; +...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...+ case ISD::FP_TO_UINT: + case ISD::FNEG: + case ISD::FABS: + case ISD::FSQRT: + case ISD::FSIN: + case ISD::FCOS: + case ISD::FPOWI: + case ISD::FPOW: + case ISD::FLOG: + case ISD::FLOG2: + case ISD::FLOG10: + case ISD::FEXP: + case ISD::FEXP2: + case ISD::FCEIL: + case ISD::FTRUNC: + case ISD::FRINT: + case ISD::FNEARBYINT: + case ISD::FFLOOR: + switch (TLI.getOperationAction(I->getOpcode(), I->getValueType(0))) { + case TargetLowering::Promote: + Result = PromoteVectorOp(SDValue(Result, 0)).getNode(); + break; +...

...CHAIN, MVT::Other, Custom); > + > + setOperationAction(ISD::SELECT_CC, MVT::f32, Custom); > + setOperationAction(ISD::SELECT_CC, MVT::i32, Custom); > + > + // Library functions. These default to Expand, but we have instructions > + // for them. > + setOperationAction(ISD::FCEIL, MVT::f32, Legal); > + setOperationAction(ISD::FEXP2, MVT::f32, Legal); > + setOperationAction(ISD::FRINT, MVT::f32, Legal); > + > + setOperationAction(ISD::UDIV, MVT::i32, Expand); > + setOperationAction(ISD::UDIVREM, MVT::i32, Custom); > + setOperationAction(ISD::UREM, M...