similar to: Return value from TargetLowering::LowerOperation?

Displaying 20 results from an estimated 4000 matches similar to: "Return value from TargetLowering::LowerOperation?"

2016 Jan 25
1
Return value from TargetLowering::LowerOperation?
Hi, On 01/22/2016 05:02 PM, Tom Stellard wrote: > On Fri, Jan 22, 2016 at 01:58:49PM +0100, Mikael Holmén via llvm-dev wrote: >> Hi, >> >> I'm a litle bit puzzled by the TargetLowering::LowerOperation function, >> and what different callers of this function assumes about the returned >> value. >> > SelectionDAGLegalize::LegalizeOp() is your best
2020 Jan 28
2
Handling node through TargetLowering::LowerOperation vs TargetLowering::ReplaceNodeResults
Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at
2020 Jan 28
2
Handling node through TargetLowering::LowerOperation vs TargetLowering::ReplaceNodeResults
Hi, I see that for different targets in classes which inherits from TargetLowering there are implemented both methods: LowerOperation and ReplaceNodeResults What decides that for one given ISD we have to add handling in LowerOperation and for other in ReplaceNodeResults, when for both SetOperationAction is configured to be Custom? Is it related with number of results of given operation and
2010 Sep 22
2
[LLVMdev] r114523 (convert the last 4 X86ISD...) breaks clang
Hello, After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: (I know I should fill a bug report instead of posting here, but I don't get much time right now). Trying to compile the following simple code, clang asserts. ---------- round.c -------- #include <math.h> float test() { return llround(1); } -------------------- [MacPro:~/Desktop]
2010 Sep 22
0
[LLVMdev] r114523 (convert the last 4 X86ISD...) breaks clang
I will take a look in the next couple hours. Feel free to revert it in the meantime, thanks! -Chris On Sep 22, 2010, at 1:53 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > Hello, > > After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: > (I know I should fill a bug report instead of posting here, but I don't get
2017 Jan 23
2
returning from LowerOperation()
Hi Eli, I would like to clarify generally what the difference is between returning SDValue() and Op (input argument unchanged) from LowerOperation()? My understanding is that returning SDValue() means that Target gives up, and the common code is supposed to handle it. Returning Op, the unchanged argument, means that the Target is happy with the node as it is, and the common code can move on
2017 Jan 23
2
returning from LowerOperation()
> On Jan 23, 2017, at 12:36, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/23/2017 5:21 AM, Jonas Paulsson wrote: >> Hi Eli, >> >> I would like to clarify generally what the difference is between returning SDValue() and Op (input argument unchanged) from LowerOperation()? >> >> My understanding is that returning SDValue()
2012 Jun 01
2
[LLVMdev] legalization of truncating stores in LegalizeDAG.cpp
In LegalizeDAG.cpp, truncating stores are custom-lowered in line 1314-1317: 1314 case TargetLowering::Custom: 1315 ReplaceNode(SDValue(Node, 0), 1316 TLI.LowerOperation(SDValue(Node, 0), DAG)); 1317 break; Is there a reason it doesn't check whether the SDValue returned from TargetLowering::LowerOperation is null before it replaces the
2012 Sep 02
2
[LLVMdev] Question regarding ReplaceValueWith and ReplaceNodeResults
Hi Duncan, > as well as what Eli said, ReplaceNodeResults requires (IIRC) the new node to > have the same type as the old node, which doesn't seem to be the case > here. Are you sure ? I see ReplaceNodeResults being called from functions such as CustomWidenLowerNode and CustomLowerNode. In the former, we are clearly expecting a change in type, aren't we? Even in the latter,
2012 Jun 01
0
[LLVMdev] legalization of truncating stores in LegalizeDAG.cpp
Hi Akira, On 01/06/12 02:27, Hatanaka, Akira wrote: > In LegalizeDAG.cpp, truncating stores are custom-lowered in line 1314-1317: > > 1314 case TargetLowering::Custom: > 1315 ReplaceNode(SDValue(Node, 0), > 1316 TLI.LowerOperation(SDValue(Node, 0), DAG)); > 1317 break; > > Is there a reason it doesn't check whether the
2009 Jan 18
2
[LLVMdev] PIC16 backend for llvm 2.5
On Fri, 2009-01-16 at 10:03 +0100, Duncan Sands wrote: > Hi Sanjiv, > > > Well the magnitude of the task is not small. > > ExpandIntegerOperand() calls LowerOperation() to allow targets to handle > > illegal operands. So we will need to change the interface of > > LowerOperation() to pass an extra argument called Results, which is an > > array of SDValue.
2011 Jun 13
1
[LLVMdev] Modifying DAG in TargetLowering::ReplaceNodeResults()
Hi! I am trying to implement va_arg() on ppc32. Everything went smooth, except implementing va_arg() of 64bit int. Since i64 is not a legal type on ppc32 DAGTypeLegalizer::ExpandRes_VAARG() splits the va_arg(i64) into two i32 va_args. The problem with ppc32 va_arg is that it needs special "alignment" of its gpr pointer when the argument is i64. Ie. I need to know if I am lowering
2009 Jan 16
2
[LLVMdev] PIC16 backend for llvm 2.5
> -----Original Message----- > From: Duncan Sands [mailto:baldrick at free.fr] > Sent: Friday, January 09, 2009 5:23 PM > To: Sanjiv Kumar Gupta - I00171 > Cc: llvmdev at cs.uiuc.edu > Subject: Re: PIC16 backend for llvm 2.5 > > Hi Sanjiv, > > > Well, the first email is here. > > > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon- >
2009 Jan 16
0
[LLVMdev] PIC16 backend for llvm 2.5
Hi Sanjiv, > Well the magnitude of the task is not small. > ExpandIntegerOperand() calls LowerOperation() to allow targets to handle > illegal operands. So we will need to change the interface of > LowerOperation() to pass an extra argument called Results, which is an > array of SDValue. Targets will push the result values in this array and > then we can replace values in
2009 Mar 04
2
[LLVMdev] Nested functions
I get the following error during compilation using the LLVM cross-compiler (x86_64->arm). error: nested functions are disabled, use -fnested-functions to re-enable With -fnested-functions switch, I get the following error: <llvm-src-dir>/llvm/lib/Target/ARM/ARMISelLowering.cpp:1439: virtual llvm::SDValue llvm::ARMTargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&):
2017 Sep 20
0
Updating LLVM Tests for Patch
Hi, I am currently working on a more or less intrusive patch (D37896), which pulls optimizations on multiplications from some back-ends, e.g., (mul x, 2^N + 1) => (add (shl x, N), x) in AArch64, into the DAGCombiner to have this optimization generic on all targets. However, running the LLVM Tests leads to 67 unexpected results. Am 19.09.2017 um 15:58 schrieb Sanjay Patel: > For the
2017 Sep 14
2
Question about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT'
Hi All, I have a question about splitting 'EXTRACT_VECTOR_ELT' with 'v2i1'. I have a llvm IR code snippet as following: llvm IR code snippet: for.body: ; preds = %entry, %for.cond %i.022 = phi i32 [ 0, %entry ], [ %inc, %for.cond ] %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> %1 = extractelement <2 x i1>
2011 Oct 18
0
[LLVMdev] Matching addsub
Hi Hal, you should probably add a target specific DAG combine that synthesizes the appropriate target instruction. This is how I handled x86 horizontal add (see the FHADD X86 opcode). If it turns out that the same thing is useful for other targets then it can be generalized later. Ciao, Duncan. On 10/18/11 00:40, Hal Finkel wrote: > How should I go about matching floating-point addsub-like
2017 Sep 20
3
Updating LLVM Tests for Patch
There are multiple problems/questions here: 1. Make sure you've updated trunk to the latest rev before running update_llc_test_checks.py on lea-3.ll. Ie, I would only expect the output you're seeing if you're running the script on a version of that test file before r313631. After that commit, each RUN has its own check prefix, so there should be no conflict opportunity. 2. I
2009 Mar 04
0
[LLVMdev] Nested functions
Hi Bharadwaj, > I get the following error during compilation using the LLVM cross-compiler > (x86_64->arm). > > error: nested functions are disabled, use -fnested-functions to re-enable yes, nested functions are disabled by default in llvm-gcc (not sure why - maybe a historical hang over from the days when they were not supported?). > With -fnested-functions switch, I get the