search for: legaliser

...ssed, argument 1 in r24, r25 and argument 2 in r22, r23. When I'm looking in the function lowering code in SelectionDAGISel::LowerArguments and AVRTargetLowering::LowerFormalArguments, we already have a problem because the 32 bit return value has been turned into two 16 bit values by the legaliser and the information has been lost that it was one 32 bit value. So the lowering code cannot correctly lower the return value and gets the two 16 bit words mixed up. Which bit of the code do people think is at fault here? What hooks need changing on AVR? Thanks for any advice or help you can...

Hi Tim, Thank you for your reply. It actually helped a lot to narrow the issue, as previously I didn’t even know where to look. I have been following the code in the debugger, specially the LSRInstance::SolveRecurse function. This function traverses recursively all possible ‘Formulae’, and determines the best instruction combination for the loop generation, based on minimal cost. The

...h corresponding increments to the address, in which case the final layout in memory is 0b01111111011111110111111101111111. Or it can be written as a packed vector which I think would resemble 0b00001111111111111111111111111111. This would mean the memory layout changes depending on how/whether the legaliser breaks large vectors down into smaller types. Is this the case? For example, <4xi32> => <4 x i31> converts to two <2 x i32> => <2 x i31> stores on a target with <2 x i32> legal but would not be split if <4 x i32> were declared legal. Thanks Jon On Fri,...

Alex, ping? There was a thread about moving Risc-V out of experimental but I think it didn't go anywhere? Separately, do the listed patches sound okay for merging? Thanks, Hans On Fri, Jan 25, 2019 at 4:40 PM Bruce Hoult <brucehoult at sifive.com> wrote: > > In https://llvm.org/svn/llvm-project/llvm/branches/release_80 I find > that RISCV is still in

On Wed, 8 Apr 2020 at 04:23, Kai Wang <kai.wang at sifive.com> wrote: > If we apply the type system pointed out by Renato, is the vector type <vscale x 1 x i16> legal? If we decide that <vscale x 1 x i16> is a fundamentally impossible type, does it contrary to the philosophy of LLVM IR as reasonably target-independent IR? I do not get the point of your argument. Hi Kai,

I come across a situation that I am having a hard time to understand. When I compile the following code : char *tst( char *dest, const char *src, unsigned int len ) { for (int i=0 ; i<len ; i++) { dest[i] = src[i]; } return dest; } Clang generates this for the ‘for’ body: for.body: ; preds = %for.cond %arrayidx = getelementptr inbounds i8,

Hi, I would like to restart the conversation regarding adding SVE support to LLVM. This time I am framing things from the code generation point of view because our immediate priority is llvm-mc support rather than auto-vectorisation. Can you please review the following text outlining MVT changes we would like to make so SVE instructions can be added to the AArch64 Target. My overriding

I'm trying to figure out how to map more complex CISC instructions now. For example on the 68000, you have things like -- add.w (a0)+,(a1)+ So that equates to: temp1 = load a0 add 2, a0 temp2 = load a1 temp1 = add temp1, temp2 store temp1, a1 add 2, a1 How do I express that in a form for LLVM? I see things like pre_store and post_store, but I cant find anything in the way of documentation

On 8 January 2011 18:27, Tobias Grosser <grosser at fim.uni-passau.de> wrote: > OK. First of all to agree on a name, we decided to call the Polyhedral > analysis we develop PoLLy, as in Polly the parrot. ;-) Maybe it was a > misleading choice? I never realised... ;) Polly it is! > In general as I explained I agree that a three stage approach is useful, > for the reasons you

Hi Richard, Thanks for working on this. We should probably move this discussion to llvm-dev because it is not strictly related to the patch review anymore. The code below is not representative of general c/c++ code. Usually only domain specific language (such as OpenCL) contain vector instructions. The LLVM pass manager configuration (pass manager builder) is designed for C/C++ compilers, not

Hi David, > On Nov 18, 2015, at 11:55 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > > Hi Quentin, > > On 18 Nov 2015, at 19:26, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> In the section “Goals", I defined (repeated for people that saw the talk) the goals for the Global ISel design. >> - Do you see

Nadav and other vectorizer folks- Is there any plan to support special idioms in the loop vectorizer like sum of absolute difference (SAD) ? We see some useful cases where llvm is losing performance at -O3 due to SADs not being vectorized (hence PSADBWs not being generated). Also, since the abs() call is already lowered to a sequence of 'icmp; neg; select' by simplifylibcalls (in -O3),

This question came about through reviewing work from Leslie Zhai on GlobalISel support for RISC-V, which also motivated me to revisit code which I've always felt was a bit clunky. Calling convention lowering in LLVM is typically handled by functions conforming to the CCAssignFn typedef: typedef bool CCAssignFn(unsigned ValNo, MVT ValVT, MVT LocVT,

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Dibyendu Das" <Dibyendu.Das at amd.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, November 4, 2014 5:23:30 AM > Subject: Re: [LLVMdev] supporting SAD in loop vectorizer > > On 4 November 2014 11:06, Das, Dibyendu <Dibyendu.Das at amd.com> wrote:

I think this is broken in at least one place when legalising the DAG. This llvm ir: %3 = call { i16, i1 } @llvm.umul.with.overflow.i16(i16 %2, i16 11) Fails to lower correctly on AVR but the problem is, unfortunately, not just coming from the AVR Target code and I am not sure it can be cleanly fixed just there. (But I would be very happy to be proved wrong as I'm very new to this.) The above

Hi Dan, If you set the node's action to "Custom", you should be able to interfere in the type legalisation phase (before it gets promoted to a 64-bit MUL) by overriding the "ReplaceNodeResults" function. You could either expand it to a different libcall directly there, or replace it with a target-specific node (say XXXISD::MUL32) which claims to take i64 types but you

This is a question about optimizing the code generation in a (new) Z80 backend: The CPU has a couple of 8 bit physical registers, e.g. H, L, D and E, which are overlaid in 16 bit register pairs named HL and DE. It has also a native instruction to load a 16 bit immediate value into a 16 bit register pair (HL or DE), e.g.: LD HL,<imm16> Now when having a sequence of loading two 16

...ave multiple "ret" instructions. It seems LLVM does not accept multiple return in a basic block by default. > Yes, if you’re inserting terminators in a basic block at the IR level, you’re going to have to split it into two different blocks yourself. Essentially you’re encountering a legaliser failure here — it’s an invariant of a BasicBlock that there are no terminator instructions in the body, and the last instruction should be a terminator. > Is there a specific optimization or pass that I can enable to remove unreachable codes in basic blocks? > If you’re writing your own pa...

> On 2 May 2017, at 8:48 am, Tom Stellard <tstellar at redhat.com> wrote: > You would probably need to write a new tablegen backend to generate > instruction tables that would be used outside of LLVM. I think I need to write one anyway because I need to generate lots of tables other than the instruction table (there are no registers and therefore no register table), at least one

On 5/3/2017 12:04 PM, Tom Stellard via llvm-dev wrote: > On 05/03/2017 11:19 AM, Nicholas Wilson wrote: >>> Right, what I was trying to say is that there are more benefits from >>> having this not be a target than there is from having it be a target. >> Please enumerate them, I have seen none posted so far . The implied “it is what all the the other backends do” w.r.t