search for: isel

All, As I've done more integrating of AVX work upstream and more tuning here, I've run across several things which are clunky in the current isel design. A couple examples I can remember offhand: 1. We have special target-specific operators for certain shuffles in X86, such as X86unpckl. I don't completely understand why but Bruno indicated it was to address inefficiecies. One of those is the need to check masks multiple tim...

> > The other thing that might work, is having TargetMachine remember how > > the fast-isel option got set, and make OptLevelChanger do the right > > thing. But that seems like a hack to work around Mips not obeying the > > specified optimization level, honestly. > > I think we should do that as well. I don't think it's right that optnone > enables Fast ISel...

Well, 'optnone' is already not identical to -O0, and given the nature of things, probably can't be; but I am persuaded that it's reasonable for it to honor the -fast-isel option as a debugging tactic. I'll take an AI to make this happen. Thanks, --paulr P.S. One nit, the "O0 + optnone" case should not have an asterisk, the FastISel flag is not manipulated if the opt level is already zero. Does not affect the strength of your argument, of course. From...

On Mar 16, 2011, at 1:44 PM, David Greene wrote: > All, > > As I've done more integrating of AVX work upstream and more tuning here, > I've run across several things which are clunky in the current isel > design. A couple examples I can remember offhand: > > 1. We have special target-specific operators for certain shuffles in X86, > such as X86unpckl. I don't completely understand why but Bruno > indicated it was to address inefficiecies. One of those is the need >...

> > I was mucking around in FastISel, and was surprised to see the test > > llvm/test/CodeGen/Mips/emergency-spill-slot-near-fp.ll > > failed. This was surprising because it specifies -fast-isel=false. > > > > Does the Mips code generator use fast-isel even when you ask it not to? > > Thanks, > >...

> > > I'd like llvm-isel-fuzzer to be added once its committed consider it done (once it's there) > (which should > be as soon as LLVM fuzzers work in release builds again). One potential > issue is that llvm-isel-fuzzer is more of a collection of fuzzers, and > it needs some arguments to run (ie, to ch...

...'t exactly match –O0 because "things break" if we turn off everything. Luckily, exactly matching –O0 isn't a requirement. Contemplating the "things break" situation, I am entirely willing to believe (it may have actually happened) that problems can occur when using FastISel in a pipeline that isn't expecting it. So, for purposes of diagnosing these 'optnone' problems, it seems useful to be able to force 'optnone' not to use FastISel. This is a different motivation than Daniel expressed, which is a more principled idea coming from the "optnon...

I have been working on improvements to TableGen's DAG Isel matcher backend. This has led me to thinking about ways to speed up the compile-time interpreter of the instruction selection matcher table. Is this worth my time, given Fast Isel and the upcoming Global Isel selector?

> > > > I was mucking around in FastISel, and was surprised to see the test > > > > llvm/test/CodeGen/Mips/emergency-spill-slot-near-fp.ll > > > > failed. This was surprising because it specifies -fast-isel=false. > > > > > > > > Does the Mips code generator use fast-isel even when you as...

It seems that fast-isel for intel does not handle strlen. It's a general problem in fast-isel . ~/llvmw/build/Deb~/llvmw/build/Debug+Asserts/bin/clang -O0 -mllvm -fast-isel-verbose -mllvm -fast-isel strlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int...

...at apple.com> writes: >> 1. We have special target-specific operators for certain shuffles in X86, >> such as X86unpckl. > It also eliminates a lot of fragility. Before doing this, X86 > legalize would have to be very careful to specifically form shuffles > that it knew isel would turn into (e.g.) unpck operations. Now > instead of forming specific carefully constructed shuffle masks (not > making sure other code doesn't violate them) it can just directly form > the X86ISD node. Right. What I've presented would reverse this. Rather than making Lega...

Given that I'm only somewhat up-to-speed on the DAG ISel scheme and not much at all on the Global ISel scheme, I'm tempted to work on the former and then the latter. So I'll look at the CodeGenDAGPatterns messages first. Then I will take a look at Global ISel. Matt: Can you suggest one or two things about Global ISel that could use some work? I...

...at follows I tried to open the file before reading but apparently without success, because the result was repeated copies of the first line: flines <- 107165 slines <- 100 selected <- sort(sample(flines,slines)) strvec <- rep(??,slines) file(?c:/data/perry/data.csv?,open="r") isel <- 0 for (iline in 1:slines) { isel <- isel + 1 cline <- readLines(?c:/data/perry/data.csv?,n=1) if (iline == selected[isel]) strvec[isel] <- cline else isel <- isel - 1 } close(?c:/data/perry/data.csv?) sel.flows <- read.table(textConnection(strvec), header=FALSE, sep=&...

Hi, I would like your opinions on the contract we have between the LLVM IR and the backends. * Context * Right now, the backends are supposed to be able to perform instruction selection on any valid LLVM IR. Although this is *not* something I want to change for GlobalISel, I thought I brought that up on the mailing list to discuss the implications. In particular, in the past, some people mentioned that they wanted to do (some part of) the legalization on LLVM IR. This may impact the contract we have between LLVM IR inputs and the backends and I would like to clarif...

Right now we're shying towards having a re-association helper in codegen-prepare that will re-associate expressions (if allowed). This would allow fast-isel to more easily spot FMA opportunities, and form better code. On Dec 12, 2012, at 5:11 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > You hit send right when I did! > For your example, do you mean that it's grouped like: > (fadd (fadd (fmul a b) (fmul c...

On Dec 12, 2012, at 5:20 PM, Eric Christopher <echristo at gmail.com> wrote: > Why not just form them via a fast IR level pass and just have patterns match in fast isel instead of trying to form code? Or are we saying the same thing? (Your words of "fast isel spot"ting and "form better code" caused me to think you mean to do optimizations within the fast isel pass). Sorry, we've kind of been jumping around a bit. I'll try to expound on...

Why not just form them via a fast IR level pass and just have patterns match in fast isel instead of trying to form code? Or are we saying the same thing? (Your words of "fast isel spot"ting and "form better code" caused me to think you mean to do optimizations within the fast isel pass). -eric On Wed, Dec 12, 2012 at 5:14 PM, Michael Ilseman <milseman at apple....

I was mucking around in FastISel, and was surprised to see the test llvm/test/CodeGen/Mips/emergency-spill-slot-near-fp.ll failed. This was surprising because it specifies -fast-isel=false. Does the Mips code generator use fast-isel even when you ask it not to? Thanks, --paulr

...: >>> 1. We have special target-specific operators for certain shuffles in X86, >>> such as X86unpckl. > >> It also eliminates a lot of fragility. Before doing this, X86 >> legalize would have to be very careful to specifically form shuffles >> that it knew isel would turn into (e.g.) unpck operations. Now >> instead of forming specific carefully constructed shuffle masks (not >> making sure other code doesn't violate them) it can just directly form >> the X86ISD node. > > Right. What I've presented would reverse this. R...

Are you talking about the type checking done in CodeGenDAGPatterns.cpp? Is it easy to post an example? At 11/18/2020 01:55 PM, Thomas Lively wrote: >Hi Paul, > >I think this would be time well spent. At least in the WebAssembly backend, the vast majority of our ISel work is still done with DAG ISel. I know this is different from the performance work you have in mind, but one of my biggest pain points working on LLVM so far has been the poor error messages from the DAG ISel pattern type checker. If you could find time to improve those error messages, I would b...