search for: irtransl

...structure before being able to work on the ISel framework itself. The prototype vehicle will be AArch64. None of the changes for GlobalISel will negatively impact the existing ISel. ** High Level Prototype Design ** As shown in the talk, the expected pipeline for the prototype is: LLVM IR -> IRTranslator -> Generic (G) MachineInstr -> Legalizer -> RegBankSelect -> Select -> MachineInstr Where: - Terms in bold are intermediate representations. - Generic MachineInstrs are machine instructions with a generic opcode, e.g., ADD, COPY. - IRTranslator: Translate LLVM IR to (G) Machine...

Hello, I just started using the GlobalISel framework. Is there a way to emit all intermediate invariants from IRTranslator to Instrution-Selection in a single instruction? It will be really handy. I mean something like '-save-temps' in clang. Best regards, Kumail Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20...

...he ISel framework itself. > > The prototype vehicle will be AArch64. None of the changes for GlobalISel will negatively impact the existing ISel. > > > ** High Level Prototype Design ** > > As shown in the talk, the expected pipeline for the prototype is: > LLVM IR -> IRTranslator -> Generic (G) MachineInstr -> Legalizer -> RegBankSelect -> Select -> MachineInstr > > Where: > - Terms in bold are intermediate representations. > - Generic MachineInstrs are machine instructions with a generic opcode, e.g., ADD, COPY. > - IRTranslator: Transla...

...lf contained, i.e., with no back links to LLVM IR, is to make the testing easier. Now, to answer the question on how we do that, I have a pragmatic answer, though I am not proud of it: We are going to write unit tests with LLVM IR as input and check the MI output of the pass, e.g.,with print-after=IRTranslator. That’s not great, but at least we can test now! > Are you intending to leverage the LIR lowering that noone is using yet? That’s a tricky question because I do not intend to work on this in the prototype timeframe and I am not fond of the way this testing works. However, yes, I believe t...

...he ISel framework itself. > > The prototype vehicle will be AArch64. None of the changes for GlobalISel will negatively impact the existing ISel. > > > ** High Level Prototype Design ** > > As shown in the talk, the expected pipeline for the prototype is: > LLVM IR -> IRTranslator -> Generic (G) MachineInstr -> Legalizer -> RegBankSelect -> Select -> MachineInstr > > Where: > - Terms in bold are intermediate representations. > - Generic MachineInstrs are machine instructions with a generic opcode, e.g., ADD, COPY. > - IRTranslator: Transla...

...el framework itself. > > The prototype vehicle will be *AArch64*. None of the changes for > GlobalISel will negatively impact the existing ISel. > > > ** High Level Prototype Design ** > > As shown in the talk, the expected pipeline for the prototype is: > *LLVM IR *-> IRTranslator -> *Generic (G) MachineInstr* -> Legalizer -> > RegBankSelect -> Select -> *MachineInstr* > > Where: > - Terms in *bold* are intermediate representations. > - Generic MachineInstrs are machine instructions with a generic opcode, > e.g., ADD, COPY. > > - I...

...he ISel framework itself. > > The prototype vehicle will be AArch64. None of the changes for GlobalISel will negatively impact the existing ISel. > > > ** High Level Prototype Design ** > > As shown in the talk, the expected pipeline for the prototype is: > LLVM IR -> IRTranslator -> Generic (G) MachineInstr -> Legalizer -> RegBankSelect -> Select -> MachineInstr > > Where: > - Terms in bold are intermediate representations. > - Generic MachineInstrs are machine instructions with a generic opcode, e.g., ADD, COPY. > - IRTranslator: Transla...

...t; >> The prototype vehicle will be AArch64. None of the changes for GlobalISel will negatively impact the existing ISel. >> >> >> ** High Level Prototype Design ** >> >> As shown in the talk, the expected pipeline for the prototype is: >> LLVM IR -> IRTranslator -> Generic (G) MachineInstr -> Legalizer -> RegBankSelect -> Select -> MachineInstr >> >> Where: >> - Terms in bold are intermediate representations. >> - Generic MachineInstrs are machine instructions with a generic opcode, e.g., ADD, COPY. >> &g...

Looking through the X86 GlobalISEL code for selecting loads and stores, I'm not seeing the creation of the MachineMemOperands I'd expect to see and do see being generated by SelectionDAG.  Is this simply an oversight, or is there some aspect of the new design which pushes us away from MMOs? Various parts of the machine instruction level optimization passes use the existence and

...(although not strictly impossible) to guess what regbank to assign. This has drastic consequences for performance on FP workloads. But this isn’t the first time we’ve had this kind of issue, and it probably won’t be the last [1]. propose that we have some form of type hint propagation done at the IRTranslator stage in order to make this whole situation easier (and faster in compile-time). Option 1) We use some form of metadata on the MIR instructions like G_LOADs to signify that the vreg defined likely has an FP IR type. IIUC the current Metadata MachineOperand type is only intended for debug info...

...ere is because if we want to experiment with combine and such in the prototype, this is the kind of information we would need. > > At the end of M1, the prototype will not be able to produce code, since we would only have the beginning of the Global ISel pipeline. Instead, we will test the IRTranslator on the generic output that is produced from the tested IR. > > > So this would be targeting Generic MachineInstr? Yes. > (Better name perhaps?). Suggestion welcome :). > Which means that it should be serializable and testable in isolation yes? Partly. The lowering of the b...

...of special purpose ports I don't see a lot of need for this, but we'll see. I think it's going to take some discipline to avoid the "every backend is a large C++ project that defines everything it needs custom”. At this point, the idea is to have the standard passes shared (i.e., IRTranslator, Legalizer, RegBankSelect, and Select) and let the targets create their own pass if they want to do more stuff. Then, if we see room for generalization, we can refactor :). This is what happens right now with the IR passes that are target specific. Sometimes those get factored out like GlobalM...

...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 *** ** IRTranslator ** Mostly done. * What’s Left? * Some instructions are not yet supported. ** Legalizer ** Core logic is present. * What’s Left? * - A lot of instructions are missing, in particular the vector ones. - Legalization of G_SEQUENCE/G_EXTRACT still up in the air for complex cases. Note: The...

...tests that make sense for each pass in the GlobalISel pipeline and for this, we need to agree on a contract. > Obviously you may have a contract inside the backend as to what IR may reach the ISel phase. We need a contract for the generic part and "support any valid LLVM IR input” for the IRTranslator is hopefully broad enough to supersede any restriction the target may have. Now, if people want to go with something narrower, that is fine, I want to make it clear though. Thanks, Q. > > - Matthias

...er later pass gets a different compile time profile? > Basically, I'd have to do more experiments to figure that one out. > > As far as where time is spent in the gisel-passes itself, on average, I saw the following on the latest CTMark experiment I ran: > Avg compile time spent in IRTranslator: 4.61% > Avg compile time spent in InstructionSelect: 7.51% > Avg compile time spent in Legalizer: 1.06% > Avg compile time spent in Localizer: 0.76% > Avg compile time spent in RegBankSelect: 2.12% > >> >>> * My usual performance benchmarking run: 8.5% slow-down...

...ater pass gets a different compile time profile? > Basically, I'd have to do more experiments to figure that one out. > > As far as where time is spent in the gisel-passes itself, on average, I > saw the following on the latest CTMark experiment I ran: > Avg compile time spent in IRTranslator: 4.61% > Avg compile time spent in InstructionSelect: 7.51% > Avg compile time spent in Legalizer: 1.06% > Avg compile time spent in Localizer: 0.76% > Avg compile time spent in RegBankSelect: 2.12% > > > * My usual performance benchmarking run: 8.5% slow-down. This was abo...

...FREEZE instruction and whether the semantics of IMPLICIT_DEF need to be changed. In SelectionDAG, FREEZE is currently handled as a simple COPY. This seems to me like SelectionDAG ignores the semantics of FREEZE, since COPY has other semantics? Also, would this be acceptable for the GlobalISel IRTranslator (even if only as a first step)? Best regards, Dominik [1] https://reviews.llvm.org/D76483 [2] https://reviews.llvm.org/D29014 P.S.: is there really no way to disable a single pass from command line? We would like to disable the DivRemPairs pass as a first workaround. -- -----------------...

...ng, I received the following summary from the script in my inbox for patches-under-review where some change was made in the past 24 hours: SUMMARY FOR kristof.beyls at arm.com<mailto:kristof.beyls at arm.com> (found 8 reviews): [3.37%/41.67%] https://reviews.llvm.org/D46018 '[GlobalISel][IRTranslator] Split aggregates during IR translation' by Amara Emerson [0.00%/100.00%] https://reviews.llvm.org/D46111 '[ARM] Enable misched for R52.' by Dave Green [0.00%/50.00%] https://reviews.llvm.org/D45770 '[AArch64] Disable spill slot scavenging when stack realignment required.' b...

...39;d match LLVM IR > rather than MIR. As you go about implementation, maybe keep this idea > in mind? That's an interesting idea. Certainly tablegenerating InstCombine ought to be possible and sharing code sounds like it ought to be doable. MIR and IR are pretty similar especially after IRTranslator (which is a direct translation) through to the Legalizer (which is the first point target instructions can until targets make custom passes). From the Legalizer to ISel, there's still likely to be a fair amount of overlap between the two as a lot of the G_* opcodes directly correspond to LL...

...not strictly impossible) to guess what regbank to assign. This has drastic consequences for performance on FP workloads. > > But this isn’t the first time we’ve had this kind of issue, and it probably won’t be the last [1]. propose that we have some form of type hint propagation done at the IRTranslator stage in order to make this whole situation easier (and faster in compile-time). > > Option 1) We use some form of metadata on the MIR instructions like G_LOADs to signify that the vreg defined likely has an FP IR type. IIUC the current Metadata MachineOperand type is only intended for d...