similar to: GlobalISEL, and MachineMemOperands?

On 9/27/19 7:33 AM, Matt Arsenault via llvm-dev wrote: > > >> On Sep 27, 2019, at 09:07, Björn Pettersson A via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Obviously we do not store into two locations (it is still a single >> two byte store). >> So is it (always) correct to interpret the list of

Hi! Does anyone know how it should be interpreted when one MI has multiple MachineMemOperands? (I've tried to find information but could not find any clear definition.) For example BranchFolder may do things like this (also see https://godbolt.org/z/iphFH4): # *** IR Dump Before Control Flow Optimizer ***: bb.0.entry: ... JCC_1 %bb.2, 5, implicit killed $eflags JMP_1 %bb.1 bb.1.s1:

I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. But what is the guarantee/constraint placed on optimization/codegen passes for maintaining the contents of a MachineMemOperand? In

Is there a reason MachineMemOperands are not guaranteed to be persisted in late optimization passes? Is there a use-case where they should be stripped? On Wed, Dec 12, 2012 at 9:50 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Dec 12, 2012, at 5:50 PM, Justin Holewinski < > justin.holewinski at gmail.com> wrote: > > > Is this documented somewhere?

On Dec 11, 2012, at 11:00 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. The MMOs provide extra,

On Dec 13, 2012, at 4:43 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Is there a reason MachineMemOperands are not guaranteed to be persisted in late optimization passes? Is there a use-case where they should be stripped? That's not really the issue, though. As an intermediate representation, MI should be reasonably self-contained. The MMOs are pointers into an

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:

Hi, GlobalISel currently drops all type information relating to the integer/FP distinction during the IR translation pass, as the LLT types only represent whether a value is a scalar/vector/pointer and it’s size/shape. To compensate, later passes use the FP operations on those values to guess what kind of value is being stored within that virtual register. This means that i32/float loads get

Hi, With this email, I would like to kick-off the development for the next instruction selector that I described during the last LLVM Dev’ Meeting. For the motivations, see Jakob’s proposal (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html>) and for the proposal, see the slides (Keynote:

I don’t think bfloat should be handled this way. What Amara is suggesting is an optimization, i.e., if we drop the information we are still correct. With bfloat, if we do an operation on float16 instead of bfloat16 this is a correctness problem. So that means that either we need to have new opcodes for bfloat or we need to carry around the floating point type in MIR. I think it would be more

Hi Daniel, I had a quick look at the language reference for bitcast and I have a different reading than what you were pointing out. Indeed, my take away is: "It is always a no-op cast because no bits change with this conversion." In other words, deleting all bitcast instructions should be fine. My understanding of the quote you’ve highlighted is that it tells C programmers that this

Hi all, After a recent upstream merge into our downstream sources we are suddenly encountering the freeze instruction in LLVM IR for div/rem pairs. This seems to be related to [1]. Our downstream target is GlobalISel only and unfortunately GlobalISel doesn't support this instruction yet, so most of our internal test-suite is now breaking due to GlobalISel not being able to translate this

> On Jan 22, 2016, at 3:17 PM, Matthias Braun <matze at braunis.de> wrote: > > >> On Jan 22, 2016, at 2:36 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I would like your opinions on the contract we have between the LLVM IR and the backends. >> >> >> * Context * >> >>

> On May 5, 2020, at 2:45 PM, Ties Stuij <Ties.Stuij at arm.com> wrote: > > Quentin: Thanks for the info. I was under the impression that the LLVM community at large would prefer to extend the IR type to a bfloat MVT type. I've made a number of patches to implement this up to a point for AArch64. I can post those on Phab and start a thread to sample opinions. Sounds good to

Hi Daniel, Thanks for the pointers, I wasn’t aware of the second thread you’ve mentioned. I may be wrong but I think LLVM-IR optimizations really treat bistcasts as no-op casts, in the sense of no instructions are required. Is there anyone that could chime in on that? However, it seems SelectionDAG sticks to the load/store semantic: "BITCAST - This operator converts between integer,

Thanks Kristof. Sounds like we'll need to investigate though I'd say it is not blocking the switch. At this point I think everybody is on board to flip the switch. @Eric, how does that sound to you? Thanks, Q > Le 1 juin 2017 à 07:46, Kristof Beyls <Kristof.Beyls at arm.com> a écrit : > > >> On 31 May 2017, at 17:07, Quentin Colombet <qcolombet at

Hi all, I added a buildbot [1] running the test-suite with -O0 -global-isel. It runs into the same 2 timeouts that I reported previously on this thread (paq8p and scimark2). It would be nice to make it green before flipping the switch. At the moment, it lives in an internal buildmaster that I've setup for this purpose. If we fix it and it proves to be stable for a week or two, I'll move

Hi all, Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I am sending this email to give a status on GlobalISel progress and situation. We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. As explained during the last developer meeting, we are aiming at

Hi, > I found this thinking quite difficult to explain. Does it make sense? It might help to link to the documentation on why bitcasts are weird on big-endian NEON: http://llvm.org/docs/BigEndianNEON.html#bitconverts Cheers, James On Tue, 12 Jan 2016 at 13:23 Daniel Sanders via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I haven't found much time to

What happens when you cascade bitcast? Are these sequences all equivalent at the IR level (i.e. do they reference the same byte from the original i128)? i128 => <16 x i8> => GEP 0 i128 => <2 x i64> => GEP 0 => <8 x i8> => GEP 0 i128 => <2 x i64> => GEP 0 => <2 x i32> => GEP 0 => <4 x i8> => GEP 0 —