search for: legalisation

I'm a new LLVM developer contributing patches for the AVR platform and I'm trying to understand which parts of the code base are malfunctioning in my case. This LLVM IR... define hidden i32 @setServoAngle3(i32) local_unnamed_addr { entry: %1 = call i32 @myExternalFunction1(i32 %0, i32 119) ret i32 %1 } declare i32 @myExternalFunction1(i32, i32) Is being lowered to this assembly

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

OK, I'm clear on scalars. Data races are thankfully OK in this context. Densely packing vectors sounds efficient and is clear in the case where lanes * width is a multiple of 8 bits. I don't think I understand how it works in other cases. If we could take store <4 x i8> truncating to <4 x i7> as an example. This can be converted into four scalar i8 -> i7 stores with

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,

...se where (#Element * sizeof(ElementType) == 128bits) as legal, with the others promoted or spilt accordingly. Floating point and boolean vector MVTs are the exception whereby the smaller than usually legal types are legal and considered to contain unpacked data within a larger container. The type legalisation of: nxv2i8 ADD(nxv2i8, nxv2i8) results in: nxv2i8 TRUNC(nxv2i64 ADD((ZERO_EXTEND MVT::nxv2i8), (ZERO_EXTEND MVT::nxv2i8))) Much of the legalisation code is common to all targets and by introducing scalable vector MVTs they also apply to SVE as long as the "scalable" flag is preserve...

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

...nted to vectorized units (like SSE or NEON), need to be legalised. Such a pass should be target specific and polly could make use of that. If polly always generate vector code (instead of reason if the number of unrolled operations are the same as the current target being compiled into), the later legalisation pass can deal with the odd sized vectors and transform into multiples of legal vector + some surplus of the module as normal instructions. Also, if the target doesn't have vector units, there could be a generic (or not) transformation to cpu instructions (if there isn't one already), so th...

...ntrol scalatization >> from the target ? IMHO scalarization is only useful in undoing domain >> specific input IR. > > The problem is that instruction selection is so late that the scalar > operations don't get optimised very much. The only pass that runs after > type legalisation and still understands the function at an operational > level is DAGCombiner, which is only block-local. > > Take for example something like: > > typedef unsigned int V4SI __attribute__ ((vector_size (16))); > void foo (V4SI *vec, unsigned int n, unsigned int x) > { >...

...with a custom translation. One can envision some kind of IRTranslationKit that has all the generic translation build into to help you in such case. Anyway, the good point with the prototype is that we will be able to experiment these things :). > > Given the way that you’re proposing to do legalisation, this seems like it should be easy (for most architectures, assigning pointers to the same register bank as integers will be a simple choice and then all of the later selection should be the same). > > On a related note, keeping pointer address spaces around in the machine IR would make thin...

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),

...by functions conforming to the CCAssignFn typedef: typedef bool CCAssignFn(unsigned ValNo, MVT ValVT, MVT LocVT, CCValAssign::LocInfo LocInfo, ISD::ArgFlagsTy ArgFlags, CCState &State); Notably, these functions are called after type legalisation so an argument/ret has been split to legal value types. In some cases you want more information than is available through this function interface, which leads to a number of backends creating their own CCState subclass: * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, Orig...

...oms 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). > > It's been a while, but this could either be that the legalisation > phase is not recognising the reduction or that the cost is not taking > into account the lowered abs(). > > What does -debug-only=loop-vectorize say about it? FWIW, I agree, this sounds like a cost-model problem. The loop-vectorizer should be able to vectorize the 'icmp; neg; se...

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 really know is the 32-bi...

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

> On 25 May 2018, at 01:46, Aaron via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > LLVM optimization pass gives an error "Terminator found in the middle of a basic block!" since basic block IR may have multiple "ret" instructions. It seems LLVM does not accept multiple return in a basic block by default. > Yes, if you’re inserting

...library that takes LLVM IR as input and > produces SPIR-V as output. > > -Tom My point is that it is duplicated effort (i.e. one for LDC, one for clang and so on), and is redundant if it is a proper target. I am willing to put in the effort to allay concerns regarding the pipelining and legalisation, but I am steadfast in my opinion that it should be a target unless the benefits of not being a target can be shown to outweigh those of being a target.

...e them, I have seen none posted so far . The implied “it is what all the the other backends do” w.r.t ISel/MC is at best(worst?) an implementation detail, and I’m still not quite sure why Chandler was so adamant about that. He seemed to imply that generating straight from the IR (as opposed to post legalisation?) introduces a direct dependance in the IR that the rest of LLVM would then be required to not break? I agree that the SPIRV backend should be insulated from changes the IR, although I’m not sure how to achieve that property. I’m also not sure how much, if at all, it would be susceptible to that to...