search for: callbr

...jyknight at google.com> >>> wrote: >>> >>>> I think this is fine, except that it stops at the point where things >>>> actually start to get interesting and tricky. >>>> >>>> How will you actually handle the flow of values from the callbr into >>>> the error blocks? A callbr can specify requirements on where its outputs >>>> live. So, what if two callbr, in different branches of code, specify >>>> _different_ constraints for the same output, and list the same block as a >>>> possible e...

...wrote: >>>>> >>>>>> I think this is fine, except that it stops at the point where things >>>>>> actually start to get interesting and tricky. >>>>>> >>>>>> How will you actually handle the flow of values from the callbr into >>>>>> the error blocks? A callbr can specify requirements on where its outputs >>>>>> live. So, what if two callbr, in different branches of code, specify >>>>>> _different_ constraints for the same output, and list the same block as a &gt...

I think this is fine, except that it stops at the point where things actually start to get interesting and tricky. How will you actually handle the flow of values from the callbr into the error blocks? A callbr can specify requirements on where its outputs live. So, what if two callbr, in different branches of code, specify _different_ constraints for the same output, and list the same block as a possible error successor? How can the resulting phi be codegened? It'd su...

...gt;>> >>>>>>> I think this is fine, except that it stops at the point where things >>>>>>> actually start to get interesting and tricky. >>>>>>> >>>>>>> How will you actually handle the flow of values from the callbr into >>>>>>> the error blocks? A callbr can specify requirements on where its outputs >>>>>>> live. So, what if two callbr, in different branches of code, specify >>>>>>> _different_ constraints for the same output, and list the same bl...

...Thu, Jun 27, 2019 at 1:29 PM James Y Knight <jyknight at google.com> > wrote: > >> I think this is fine, except that it stops at the point where things >> actually start to get interesting and tricky. >> >> How will you actually handle the flow of values from the callbr into the >> error blocks? A callbr can specify requirements on where its outputs live. >> So, what if two callbr, in different branches of code, specify _different_ >> constraints for the same output, and list the same block as a possible >> error successor? How can the resu...

...> int vogon(unsigned a, unsigned b) { > asm goto("poetry %0, %1" : : "r"(a), "r"(b) : : error); > return a + b; > > error: > return -1; > } > > into the following LLVM IR: > > define i32 @vogon(i32 %a, i32 %b) { > entry: > callbr void asm sideeffect "poetry $0, $1", "r,r,X" > (i32 %a, i32 %b, i8* blockaddress(@vogon, %return)) > to label %asm.fallthrough [label %return] > > asm.fallthrough: > %add = add i32 %b, %a > br label %return > > return: > %retval.0...

...ote: On Thu, Jun 27, 2019 at 1:29 PM James Y Knight <jyknight at google.com<mailto:jyknight at google.com>> wrote: I think this is fine, except that it stops at the point where things actually start to get interesting and tricky. How will you actually handle the flow of values from the callbr into the error blocks? A callbr can specify requirements on where its outputs live. So, what if two callbr, in different branches of code, specify _different_ constraints for the same output, and list the same block as a possible error successor? How can the resulting phi be codegened? This is whe...

...; asm goto("poetry %0, %1" : : "r"(a), "r"(b) : : error); >> return a + b; >> >> error: >> return -1; >> } >> >> into the following LLVM IR: >> >> define i32 @vogon(i32 %a, i32 %b) { >> entry: >> callbr void asm sideeffect "poetry $0, $1", "r,r,X" >> (i32 %a, i32 %b, i8* blockaddress(@vogon, %return)) >> to label %asm.fallthrough [label %return] >> >> asm.fallthrough: >> %add = add i32 %b, %a >> br label %return >> &...

What about SelectionDAG representation? Currently we expand callbr to INLINEASM_BR and BR. Both of which are terminators. But in order to support outputs we would need to put CopyFromReg nodes between them. ~Craig On Thu, Jun 27, 2019 at 12:18 PM Nick Desaulniers via cfe-dev < cfe-dev at lists.llvm.org> wrote: > + CBL mailing list > > > On Th...

...e is required to be > a landing pad. On the contrary, "asm-goto" can support many output labels > in addition to fall through one and those labels represent regular code, > not landing pads. > > Hence, there is a need for introducing a new IR instruction. > > > The callbr instruction > ----------------- > > Our proposed approach is to introduce a new IR instruction named callbr > with the following syntax: > > callbr <return_type> <callee> (<argtype1> <arg1>, ...) to > label %normal or jump [label %transfe...

..."asm-goto" can support many output labels >>> in addition to fall through one and those labels represent regular code, >>> not landing pads. >>> >>> Hence, there is a need for introducing a new IR instruction. >>> >>> >>> The callbr instruction >>> ----------------- >>> >>> Our proposed approach is to introduce a new IR instruction named callbr >>> with the following syntax: >>> >>> callbr <return_type> <callee> (<argtype1> <arg1>, .....

Hi, docs seem to be broken. e.g. r353563 adds docs for callbr, but https://llvm.org/docs/LangRef.html doesn't have it. trying to build the docs manually on my box: ninja docs-llvm-html FAILED: docs/CMakeFiles/docs-llvm-html cd /usr/local/google/home/kcc/llvm-build/docs && /usr/bin/sphinx-build -b html -d /usr/local/google/home/kcc/llvm-build/doc...

...on't help the bots that build the docs, right? > > Cheers, > Jonas > > On Tue, Feb 12, 2019 at 10:17 AM Kostya Serebryany via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> docs seem to be broken. >> e.g. r353563 adds docs for callbr, but >> https://llvm.org/docs/LangRef.html doesn't have it. >> >> trying to build the docs manually on my box: >> ninja docs-llvm-html >> >> FAILED: docs/CMakeFiles/docs-llvm-html >> cd /usr/local/google/home/kcc/llvm-build/docs && /usr/bin/sphi...

MachineBasicBlock allows for multiple terminators. Unconditional branches and returns are marked as terminators; the MIPS backend also marks conditional branches as terminators. The MachineBasicBlock then has a helper function getFirstTerminator which iterates from the first terminator to the end of the MBB. So it seems to me that an MBB is a kind of superblock, single entrance and multiple side