search for: canlowerreturn

I've got it working on x86. Most of the logic is in SelectionDAGBuild and friends, but there is one target-specific hook (TargetLowering::CanLowerReturn) that needs to be implemented for each target. It should return true if the function can return the value in registers without crashing, and false if the function needs to have a hidden sret-parameter inserted to do the return; i.e., if the aggregate is too large to fit in the registers. The impl...

...retFour: # @retFour .Leh_func_begin1: # BB#0: movaps .LCPI1_0, %xmm0 ret This would of course leave the responsibility of ignoring the 4th lane to the caller. Debugging the code generation, I notice that the v3i32 is widened to v4i32, but when X86TargetLowering::CanLowerReturn, the v3i32 is seems to be split up into three MVT::i32s. If trying with a function that returns a vector of 2 or 4, CanLowerReturn-function gets a MVT::v2i32 or MVT::v4i32, respectively and return by pointer is not used. Where is the v3i32, widened to v4i32, split up into (three?) separate i32s...

On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote: > Promoting the return value is unsafe for bool returns on x86-64, which in the latest revision of the ABI only guarantees that the top 7 bits of the 8-bit register are 0. My comment is a bit off, because the question of what type to make the return value is somewhat orthogonal to the question of which zext assert we should add. Cameron

...mewhat orthogonal to the question of which zext > assert we should add. I'm not sure I follow. Won't a zeroext attribute on a bool return value ensure that it will be zero-extended to 32 bits by the callee? Or does the X86 backend consider such functions unlowerable (via TargetLowering::CanLowerReturn()) and thereby bypass the extension to 32 bits in SelectionDAGBuilder::visitRet() making a promotion in the caller unnecessary? -Ken

Hi All, In the target we are implementing, function return for i64 and f64 types has a different processing. For types i8 to i32, and f32, the return values are stored in their designated return registers (like how other targets does it). For i64 and f64 types, in the function call, after pushing the function parameters into the stack, the address of the allocated return memory space is

...f two ways to go about generating one. First, you can edit the call lowering code in clang (clang/lib/CodeGen/TargetInfo.cpp) so the pointer is represented explicitly in IR. Second, you can make the target-independent backend code generate an sret argument in SelectionDAG, by making your target’s “CanLowerReturn” return false. Probably making CanLowerReturn return false for i64 makes sense for your target. If you’re using TableGen’ed calling conventions (*CallingConv.td), the TableGen’ed code will handle this automatically; otherwise, you can write it out explicitly in C++. If you want an example of how...

...f two ways to go about generating one. First, you can edit the call lowering code in clang (clang/lib/CodeGen/TargetInfo.cpp) so the pointer is represented explicitly in IR. Second, you can make the target-independent backend code generate an sret argument in SelectionDAG, by making your target’s “CanLowerReturn” return false. Probably making CanLowerReturn return false for i64 makes sense for your target. If you’re using TableGen’ed calling conventions (*CallingConv.td), the TableGen’ed code will handle this automatically; otherwise, you can write it out explicitly in C++. If you want an example of how...