search for: fp_extend

...8,13 @@ > case MVT::f32: > case MVT::f64: > - if (isVarArg && isPPC64) { > + if (isVarArg || isPPC64) { > // Float varargs need to be promoted to double. > if (Arg.getValueType() == MVT::f32) > Arg = DAG.getNode(ISD::FP_EXTEND, MVT::f64, Arg); > > This changes the darwin/ppc ABI. It's not clear to me that this was > intended, so I just left it out. > Ah yes, I changed this and forgot to mention it (it deserves a different commit - it's, as you noticed not, directly related to the linux/ppc abi)....

...in which the DAG conversion is Can anyone help with: I have some C code test like: float x; printf("%f", x); which clang coverts to: %0 = load float* @x, align 4 %conv = fpext float %0 to double The issue is for simple Float to Double extension, the DAGCombiner.cpp DAGCombiner::visitFP_EXTEND(SDNode *N) is making a decision to do a load extension, and it translates into doing a simple double load. But problem is that my target can't simple load 8 bytes from the 4 byte float memory location to do a conversion to double. But what I need is for the DAG conversion to respect that the...

...ply was this one: @@ -1392,12 +1418,13 @@ case MVT::f32: case MVT::f64: - if (isVarArg && isPPC64) { + if (isVarArg || isPPC64) { // Float varargs need to be promoted to double. if (Arg.getValueType() == MVT::f32) Arg = DAG.getNode(ISD::FP_EXTEND, MVT::f64, Arg); This changes the darwin/ppc ABI. It's not clear to me that this was intended, so I just left it out. Thanks a lot for these patches. How well does linux/ppc work now? -Chris -- http://nondot.org/sabre/ http://llvm.org/

I'd like to start a discussion about how clang supports _Float16 for target architectures that don't have direct support for 16-bit floating point arithmetic. The current clang language extensions documentation says, "If half-precision instructions are unavailable, values will be promoted to single-precision, similar to the semantics of __fp16 except that the results will be stored

...MVT::f32: >> case MVT::f64: >> - if (isVarArg && isPPC64) { >> + if (isVarArg || isPPC64) { >> // Float varargs need to be promoted to double. >> if (Arg.getValueType() == MVT::f32) >> Arg = DAG.getNode(ISD::FP_EXTEND, MVT::f64, Arg); >> >> This changes the darwin/ppc ABI. It's not clear to me that this was >> intended, so I just left it out. >> > Ah yes, I changed this and forgot to mention it (it deserves a different > commit - it's, as you noticed not, directly related...

...h easier and cleaner. - As a consequence, the isel dags are in a more 'normal form'. I.e. it relies less on funny nodes FP_TO_FP16 and FP16_TO_FP, which are funny because they perform float up/down converts and produce i32 values by moving from/to integer and float registers. Instead, FP_EXTEND and FP_ROUND nodes will be introduced, so this is more a clean up rather than e.g. addressing a correctness issue. Unfortunatly I found that I can't completely get rid of nodes FP16_TO_FP, see 'Custom Lowering' below. - When these FP_EXTEND and FP_ROUND are introduced by the legal...

Evan Cheng wrote: > I think the easiest thing for you to do is to define a separate CALL > instruction with a different set of Defs. This instruction should > only be selected when the predicate isMacho is true. Also update > PPCRegisterInfo.cpp getCalleeSavedRegs() to return a different list > when subtarget->isMachoABI() is true. > Alright, thx Evan, that's

I just tried building the latest clang following the instructions in http://clang.llvm.org/get_started.html, and got this error when trying to compile at test program: /usr/bin/ld: cannot find /home/davem/clang-235334/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.asan-x86_64.a: No such file or directory This thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084175.html indicates

...IIC_fpCVTSH, "vcvtb", ".f32.f16\t$Sd, $Sm", [(set SPR:$Sd, (fpextend HPR:$Sm))]>, // <~~~~ new match rule using HPR and SPR Requires<[HasFP16]>, Sched<[WriteFPCVT]>; This new rule matches and fp_extend that consumes an HPR and produces a result in SPR. And that's essentially it and all the code changes I want to make. With these changes, I want to see an fadd with two f16 opernands being codegen'd, and also I want to keep the existing tests passing of course. The problem: ------------...

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd.

...IIC_fpCVTSH, "vcvtb", ".f32.f16\t$Sd, $Sm", [(set SPR:$Sd, (fpextend HPR:$Sm))]>, // <~~~~ new match rule using HPR and SPR Requires<[HasFP16]>, Sched<[WriteFPCVT]>; This new rule matches and fp_extend that consumes an HPR and produces a result in SPR. And that's essentially it and all the code changes I want to make. With these changes, I want to see an fadd with two f16 opernands being codegen'd, and also I want to keep the existing tests passing of course. The problem: ------------...

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

...= ExpandLibCall(LC, Node, false/*sign irrelevant*/, Dummy); - break; } - case Promote: - Tmp1 = PromoteOp(Node->getOperand(0)); - Result = DAG.UpdateNodeOperands(Result, LegalizeOp(Tmp1)); - Result = LegalizeOp(Result); - break; - } break; case ISD::FP_EXTEND: { @@ -4208,17 +3506,8 @@ Result = EmitStackConvert(Node->getOperand(0), SrcVT, DstVT, dl); break; } - switch (getTypeAction(Node->getOperand(0).getValueType())) { - case Expand: assert(0 && "Shouldn't need to expand other operators here!"); -...

On Fri, Oct 27, 2017 at 1:50 AM, David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This seems slightly inverted. As I understand it, the root of the problem > is that some standards, such as C, C++, and POSIX, define some functions as > special and we rely on their specialness when optimising. Unfortunately, > the specialness is a property of the source