search for: tablegen'ed

...umbed a lot of the current debug info syntax support in) >>> >>> Visitor seems plausible though I haven't looked at the code in detail to see if it'd work perfectly. >>> >>> > SGTM!  There was a hope (not quite a plan) that these would eventually be tablegen'ed, but visitor sounds fine to me too. > >> Something (anything) along these lines seems like a good idea to me. In addition to the cost of adding new nodes, having less repetitive manually-written existing code reduces the chances for bugs and increases readability. There are some ir...

Hi All, In the target we are implementing, function return for i64 and f64 types has a different processing. For types i8 to i32, and f32, the return values are stored in their designated return registers (like how other targets does it). For i64 and f64 types, in the function call, after pushing the function parameters into the stack, the address of the allocated return memory space is

...the pointer is represented explicitly in IR. Second, you can make the target-independent backend code generate an sret argument in SelectionDAG, by making your target’s “CanLowerReturn” return false. Probably making CanLowerReturn return false for i64 makes sense for your target. If you’re using TableGen’ed calling conventions (*CallingConv.td), the TableGen’ed code will handle this automatically; otherwise, you can write it out explicitly in C++. If you want an example of how this works in practice, try something like “echo 'define i128 @foo() { ret i128 3 }' | llc -mtriple=i686”. If you...

...urrent debug info syntax support in) >>>> >>>> Visitor seems plausible though I haven't looked at the code in detail to see if it'd work perfectly. >>>> >>>> >> SGTM! There was a hope (not quite a plan) that these would eventually be tablegen'ed, but visitor sounds fine to me too. >> >>> Something (anything) along these lines seems like a good idea to me. In addition to the cost of adding new nodes, having less repetitive manually-written existing code reduces the chances for bugs and increases readability. There are...

...e has been only one new kind added in the last few years. However, in my humble opinion, it would make it easier to add richer information allowing those of us extending LLVM to create better debuggers/debugging experiences. SGTM! There was a hope (not quite a plan) that these would eventually be tablegen'ed, but visitor sounds fine to me too. > Something (anything) along these lines seems like a good idea to me. In addition to the cost of adding new nodes, having less repetitive manually-written existing code reduces the chances for bugs and increases readability. There are some irregularit...

...the pointer is represented explicitly in IR. Second, you can make the target-independent backend code generate an sret argument in SelectionDAG, by making your target’s “CanLowerReturn” return false. Probably making CanLowerReturn return false for i64 makes sense for your target. If you’re using TableGen’ed calling conventions (*CallingConv.td), the TableGen’ed code will handle this automatically; otherwise, you can write it out explicitly in C++. If you want an example of how this works in practice, try something like “echo 'define i128 @foo() { ret i128 3 }' | llc -mtriple=i686”. If you...

> On May 29, 2018, at 12:28 PM, David Blaikie <dblaikie at gmail.com> wrote: > > +some of the debug info cabal (& Duncan, as an emeritus member, and person who plumbed a lot of the current debug info syntax support in) > > Visitor seems plausible though I haven't looked at the code in detail to see if it'd work perfectly. > > On Tue, May 29, 2018 at 7:56

...Patterns being matched depend on a canonical form, instructions nearly matching those patterns might be created, and then suboptimally consumed (i.e. further transformed), before being subject to the canonicalizing transformation(s) that would make the better pattern actually match. Except for TableGen'ing the whole thing, and making an actual graph automaton to match the patterns, it's not clear to me how to efficiently fix this. In the mean time, what we've been doing in practice, is that we have InstCombine patterns depend on canonical forms, until we hit some phase-ordering pr...

Could we expose predicates defined in the target InstrInfo.td file to the MachineVerifier? We use BuildMI() to create many instructions after ISEL, but the predicates are not being checked at this point. Thus, I could forget to check the target and build an instruction that is illegal for a specific configuration. In such a case it would be nice if the MachineVerifier could detect this for me.

I'm trying to add support for inline assembly and I keep getting this error: <jal> "<inline asm>:1:2: error: invalid instruction" which is due to the fact that MatchInstructionImpl() returns Match_MnemonicFail. This function is tablegen'ed in XXXGenAsmMatcher.inc and for some reason it can't find JAL even though I can clearly see it in both MatchTable0[] and MnemonicTable The input was int main () { asm volatile ("JAL"); return 0; } If I go to JAL's definition in XXXInstrInfo.td and change its assembly str...

Hi Pavel, We (the Native Client team) are also interested in helping you get these reviewed and in, especially the x86 backend stuff. Native Client's x86-64 ABI is similar to x32 so we could probably share a good portion of the code if it's structured the right way. -Derek On 1404316081542, Dmitri Gribenko <gribozavr at gmail.com> wrote: > On Wed, Jul 2, 2014 at 3:59 PM, Pavel

...form, instructions nearly > matching those patterns might be created, and then suboptimally > consumed (i.e. further transformed), before being subject to the > canonicalizing transformation(s) that would make the better > pattern actually match. > > Except for TableGen'ing the whole thing, and making an actual > graph automaton to match the patterns, it's not clear to me how to > efficiently fix this > > > That is what people used to do, make parsing grammars, etc. > Stratego is also quite efficient at term rewriting, from what...

This can't be an instsimplify though? The values we want in these cases do not exist already: %res = or i8 %b, %a %res = or i1 %cmp, %c On Thu, Jul 13, 2017 at 5:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Thu, Jul 13, 2017 at 2:12 PM, Sanjay Patel <spatel at rotateright.com> > wrote: > >> We have several optimizations in InstCombine