similar to: [LLVMdev] SelectionDAGBuilder doing bad things on certain architectures

Hi, I am new to LLVM. I am experimenting with a toy backend. I don't understand "LowerFormalArguments didn't return a valid chain" in SelectionDAGBuilder.cpp file. What is the interface here? What does it mean by returning a Chain? Thanks Jen. -------------- next part -------------- An HTML attachment was scrubbed... URL:

The following problems happens with architectures, where stack alignment is smaller than the biggest preferred alignment for any data type SP pointer may point anywhere with alignment of stack alignment (4 in our case) SelectionDAGBuilder however calls CreateStackObject with preferred alignment is given data type(8 in our problemaric case. The ABI alignment for this data type is only 4) This

I ran into some odd code being generated today and I came across something that doesn't look quite right. In SelectionDAGBuilder::visitShuffleVector there's some code to see if we can convert the shuffle to an EXTRACT_SUBVECTOR. After computing min/max values of the mask for each operand, there's a look that looks at the ranges and determines whether an EXTRACT_SUBVECTOR can be used:

I posted to llvmdev a few months ago to ask for advice on the best way to avoid the SelectionDAGBuilder from imposing a constraint whereby a volatile load would be serialised relative to all pending loads. The LLVM LRM says that a volatile load only needs to be serialised relative to other volatile loads and, while it may not matter to most targets, the current behaviour of the SelectionDAGBuilder

Hi Talin, I think that the framework for GC assumes llvm.gcroot to be in the first block. If it is not the case in your example, it will break these assumptions. Nicolas On Sun, Sep 26, 2010 at 1:38 AM, Talin <viridia at gmail.com> wrote: > I'm working on the code to handle GC tracing of "intermediate values" (as > described in the GC doc), and I've run into a

On Jul 26, 2012, at 12:57 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> +<p>This function returns the same values as the libm <tt>floor</tt> functions >> + would, and handles error conditions in the same way.</p> > > Why the intrinsic then? So that it's possible to access the ISD::FFLOOR SDNode without having to enable a

I'm working on the code to handle GC tracing of "intermediate values" (as described in the GC doc), and I've run into a weird problem. (Note, this has nothing to do with the patch I have proposed, this error occurs with regular old pointer-allocas.) The exception I am getting occurs in this code here in SelectionDAGBuilder.cpp: *case* *Intrinsic*::gcroot: *if* (GFI) {

On Oct 5, 2012, at 2:11 PM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Is it possible to not make it 'Target*'? I'm spending a lot of time moving TargetData out, would hate to have to do it again at some point in the future for TargetVectorData. :) There is an important difference here (and a common point of confusion) between TargetData and the the stuff

I'm trying to track down the problem with the assertion failure in SelectionDAGBuilder.cpp. This is the code: *case* *Intrinsic*::gcroot: *if* (GFI) { *const* Value *Alloca = I.getArgOperand(0); *const* Constant *TypeMap = cast<Constant>(I.getArgOperand(1)); * FrameIndexSDNode *FI = cast<FrameIndexSDNode>(getValue(Alloca).getNode());*

On Wed, 2012-02-08 at 17:26 -0800, Chris Lattner wrote: > On Feb 7, 2012, at 12:10 PM, Hal Finkel wrote: > >>> 1. "Target Data" for vectorization - I think that in order to improve > >>> the vectorization quality, the vectorizer will need more information > >>> about the target. This information could be provided in the form of a > >>>

On Wed, 2012-02-08 at 17:26 -0800, Chris Lattner wrote: > On Feb 7, 2012, at 12:10 PM, Hal Finkel wrote: > >>> 1. "Target Data" for vectorization - I think that in order to improve > >>> the vectorization quality, the vectorizer will need more information > >>> about the target. This information could be provided in the form of a > >>>

On Feb 7, 2012, at 12:10 PM, Hal Finkel wrote: >>> 1. "Target Data" for vectorization - I think that in order to improve >>> the vectorization quality, the vectorizer will need more information >>> about the target. This information could be provided in the form of a >>> kind of extended target data. This extended target data might contain:

Hello All, the patch below adds a target lowering hook to state that the target supports (or not) floating point exception behavior. The patch is small and contains one possible use for the hook (folding potentially exception raising fp operations). Any comments? Thanks Pedro -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: opensource1.txt

> Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use the TLI > interface which can answer questions such as "is this operation supported ?" > or "is this type legal". This is a subset of what we need in a vectorized. > We can discuss other requirements that the vectorizer may have after we > finish with the first phase. I suspect that we may

> -----Original Message----- > From: David Greene [mailto:dag at cray.com] > Sent: Friday, February 22, 2019 2:40 PM > To: Robinson, Paul > Cc: asb at lowrisc.org; clattner at nondot.org; llvm-dev at lists.llvm.org; > nd at arm.com > Subject: Re: [llvm-dev] RFC: changing variable naming rules in LLVM > codebase > > via llvm-dev <llvm-dev at lists.llvm.org>

I assume you meant to ask for ports that *don’t* support floating point exceptions. To my knowledge, neither R600 nor NVPTX support floating point exceptions. —Owen > On Aug 8, 2014, at 2:41 PM, Eric Christopher <echristo at gmail.com> wrote: > > There's a lot of cut and paste in those routines. Can you do something > to unify it a bit? Also, do we have any ports that

Hello. I'm having problems at instruction selection with my back end with the following basic-block due to a vector add with immediate constant vector (obtained by vectorizing a simple C program doing vector sum map): vector.ph: ; preds = %vector.memcheck50 %.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0

On Mon, 2012-02-06 at 14:26 -0800, Chris Lattner wrote: > On Feb 2, 2012, at 7:56 PM, Hal Finkel wrote: > > As some of you may know, I committed my basic-block autovectorization > > pass a few days ago. I encourage anyone interested to try it out (pass > > -vectorize to opt or -mllvm -vectorize to clang) and provide feedback. > > Especially in combination with

Hi Eric, On Oct 5, 2012, at 11:29 AM, Eric Christopher <echristo at gmail.com> wrote: >> Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use the TLI >> interface which can answer questions such as "is this operation supported ?" >> or "is this type legal". This is a subset of what we need in a vectorized. >> We can discuss other

Hello. In order to detect a problem in the initial selection DAG creation that I have in my back end I need to output detailed debug info from the SelectionDAG.cpp module with all the TableGen records that are being processed, and compare between a working back end and my buggy back end. I can debug by adding myself DEBUG() statements in the visit*() methods of the SelectionDAG.cpp