search for: sdisel

...écrit : > > Quentin Colombet <quentin.colombet at gmail.com> writes: > > > And are there any realistic alternatives for declarative > > representations combines? > > > > Realistic I would have thought we can use the syntax we already have > > for SDISel. > > In other words, people wouldn’t have to learn yet another way of doing > > combines and when we are ready we can move everything (isel + > > combines) in one go. > > I don't think I'd want to see things go that way. Current SDISel > patterns are very limited...

...talk16). Note: That does not mean the design is settle nor that we won’t change the APIs. Note: A lot of the things listed in this email is a reminder of what we said during the dev meeting talk. *** High Level View *** As of r292481, we compile and run correctly with GISel (without fall back to SDISel) 63% of the LLVM test suite. If you are interested in detailed numbers, please see the attachments (courtesy of Kristof Beyls). Note: The compile time numbers are probably noisy (compiled in parallel on the same machine), and not relevant at this point of the project anyway. *** Per Pass Status...

...e > path forward? Should we have more examples of existing combines being > represented in this way as evidence? > > And are there any realistic alternatives for declarative representations > combines? > Realistic I would have thought we can use the syntax we already have for SDISel. In other words, people wouldn’t have to learn yet another way of doing combines and when we are ready we can move everything (isel + combines) in one go. > Amara > > > Now, again you're the one doing the work, so if you believe this step > brings us closer to the final design,...

...e are close to the point of enabling it by default on AArch64 at O0. We now would like to enlist your help to get there. *** Quick Status *** On iOS we are at 100% pass rate in 00 g for the LLVM test suite, standard benchmarks and unit tests. In about 5% of all functions GlobalIsel falls back to SDIsel. (Kristof Beyls would have the linux numbers.) The self host compiler correctly builds and runs the LLVM test suite in O0. *** We Need Your Help *** Please try GlobalISel for AArch64 at O0 (preferably O0 g) and file PR for: - Performance problems (compile time, runtime, code size) - Miscompile -...

...olombet at apple.com> wrote: > > Hi Amara, > > I’ve done that internally for testing purposes and basically the existing GISel pipeline with fallbacks just did what I wanted. > In other words, I always used the GISel pipeline but I added an attribute that triggered a fallback to SDISel for the functions I wanted to compile with SDISel. I had to disable the global-isel-abort thing though. That said, that should be easily fixable. > > For the record, I was doing the attribute check in lowerFormalArgument IIRC. I.e., something that is called for every single function at the b...

...ne user? Is it valid if there are more that one users, if we cannot move something into the destination block can we still apply the pattern is we move the result in the source block, etc. The number of users may not be that relevant, but this gives use is a notion of profitability (it is just how SDISel does this). This actually ties back to the inter-basic-block case: is this pattern profitable if it is between basic blocks with different frequencies. In other words, I believe we should start to think in terms of how profitable is a pattern. E.g., the source pattern as some cost and the destinati...

Hi all. I’m trying to get GlobalISel to work better with LTO. At the moment if you enable it via -fglobal-isel, it only adds the -mllvm -global-isel and related options to the cc1 invocation. With LTO, that doesn’t work as we need to encode codegen options into the bitcode, usually via function attributes. Does anyone have any ideas on how to achieve this? The only way I can see it working is if

...optimize byval functions, no pic/got code for non-local calls. On x86 no support for pic/got code on x86-64 for non-local calls. > I am not sure. Just thinking aloud. It would be nice if all of the > common code can be handled by SelectionDAGISel. For example, it seems > possible for SDIsel to determine which operands can be overwritten and > issued the copies there? > > Yes the common code between x86/ppc could be moved to SelectionDAGISel. See CheckDAGForTailCallsAndFixThem(). > There seem to be quite a bit of duplicated code. Can you refactor? Created LowerMemOpCallTo....

...and I am > > afraid that MIR is not the right abstraction for that. > > What do you mean by "prototype different approaches quickly"? I mean exploring different combine strategies :). With a model we are stuck with what it was designed to express. For instance, currently with SDISel there are no way to express something like paired loads, i.e., patterns like this: load @a, load @a + 4 => loadpair @a Because the DAGs needs to be single rooted. In C++ we do whatever we want (I am not saying it is easy ;).) > > It's funny, because I always thought the exact opposit...

Can you elaborate on the fix you are thinking of? I'm not sure what you're thinking should change. On Tue, Nov 19, 2019 at 3:51 PM Quentin Colombet <qcolombet at apple.com> wrote: > It sounds to me that we should fix SDISel to accept both physical and > virtual definitions on variadic instructions. Though I wouldn’t bother > adding the support for implicit virtual definition. > > I don’t think we need a bit to allow if we go that direction. > > On Nov 19, 2019, at 10:29 AM, Thomas Lively <tlively...

...fully support PIC. > > Also > +static bool IsPossiblyOverwrittenArgumentOfTailCall(SDOperand Op, > + MachineFrameInfo > * MFI) { > > I wonder if these can be moved to SelectionDAGISel? So it's handled > during the sdisel phase of call lowering? I am not sure what you mean by 'these' here. The function above (IsPossiblyOverwritten...) is used in LowerCALL() forall arguments CalculateTailCallArgDest() to determine whether an argument needs to be evacuated to a virtual register to prevent being overwrit...

...bots For people not developing on GlobalISel, it will: - Test that GlobalISel still works with your changes (make check will test that for you) - Allow you to play with it! Basically flipping the default CMake setting will give access to all the ISel schemes that we have in LLVM, instead of just SDISel and FastISel. * Downsides * For people developing on GlobalISel, it will: - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots For people not developing for GlobalISel, it will: - Increase the compile time since t...

...t; >> Also >> +static bool IsPossiblyOverwrittenArgumentOfTailCall(SDOperand Op, >> + MachineFrameInfo >> * MFI) { >> >> I wonder if these can be moved to SelectionDAGISel? So it's handled >> during the sdisel phase of call lowering? > > I am not sure what you mean by 'these' here. The function above IsEligibleForTailCallOptimization, IsPossiblyOverwrittenArgumentOfTailCall, etc. Basically anything that's shared between all the targets. > > (IsPossiblyOverwritten...) is used...

...t developing on GlobalISel, it will: > - Test that GlobalISel still works with your changes (make check will test that for you) > - Allow you to play with it! > > Basically flipping the default CMake setting will give access to all the ISel schemes that we have in LLVM, instead of just SDISel and FastISel. > > * Downsides * > > For people developing on GlobalISel, it will: > - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots > > For people not developing for GlobalISel, it will:...

>> In an ideal world, we'll just need flags on load/ >> store nodes because the pointer registers will already be lowered to >> some other regclass. > > I assume malloc's and memcpy's would need them as well? Yeah, seems likely. I think malloc gets lowered in SDISel to a call though, so maybe it doesn't need it. I'm not sure what "malloc from alternate address space" really means though. There can only be one function named "malloc" :). Maybe LangRef should explicitly ban the malloc instruction from returning a pointer to...

...getting to the pointer type. Hrm, the codegen has a couple of interesting crazy issues. For example, it thinks there is a current PointerTy() that is always valid. I see a couple ways to handle this. One is to require that the targets custom expand the load/store to alternate address space at SDISel time. This way they could do any crazy thing they want, including lowering them into intrinsics, etc. -Chris -- http://nondot.org/sabre/ http://llvm.org/

...rm, the codegen has a couple of interesting crazy issues. For > example, > it thinks there is a current PointerTy() that is always valid. > > I see a couple ways to handle this. One is to require that the > targets > custom expand the load/store to alternate address space at SDISel > time. > This way they could do any crazy thing they want, including > lowering them > into intrinsics, etc. Forcing custom lowering for ISD::LOAD/STORE means that you lose lots of the information carried along with the Load/StoreSDNode that makes writing instruction patterns...

...nyone looking at this? The bug is unassigned... Ahmed, can you have a look? > Not yet, I will try to follow up on this tomorrow. > LowerCallTo has a comment that worries me: > > /// FIXME: When all targets are > /// migrated to using LowerCall, this hook should be integrated into SDISel. > > Does that mean if LowerCall is called directly, it won't fix the tail > call reusing the stack pointer? Can they be called interchangeably by > the same back-end on different occasions? > Not sure, the tests only fail on i386. I can't reproduce on amd64. -Tom >...

I'm digging into this, but I'd like to know if it's feasible to get to the pointer type from a Load/Store SDNode? This would relieve me from having to put the address space information into those SDNodes. Is Load/StoreSDNode->getSrcValue()->getType() going to do what I want? If not, I can't see another way of getting to the pointer type. -- Christopher Lamb

...e give it a try! > > On 30 March 2017 at 00:27, Quentin Colombet <qcolombet at apple.com> > wrote: > > On iOS we are at 100% pass rate in 00 g for the LLVM test suite, > > standard benchmarks and unit tests. In about 5% of all functions > > GlobalIsel falls back to SDIsel. > > (Kristof Beyls would have the linux numbers.) The self host compiler > > correctly builds and runs the LLVM test suite in O0. > > Having done no tests at all on my side, I think we need to have similar > numbers on Linux to be able to flip across the board. > > I d...