search for: ehpads

Yes, it's still respected in this case, as the only instructions that will be deleted have been RAUW with undef. Originally, all instructions where RAUW but only non-EHPad were deleted (that means EHPad were RAUW but not deleted). Then it was later patched by not RAUW token instructions and now not deleting EHPad nor token instructions. My assumption is that the instructions we wanted to

I did not observe any assertion. In addition, the documentation ( https://llvm.org/docs/LangRef.html#undefined-values) says: The string ‘undef’ can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern. Undefined values may be of any type (other than ‘label’ or ‘ void’) and be used anywhere a constant is permitted. Either way,

Hello David, I am having an issue with some custom intrinsics that return a token value: InstCombine deletes the users of the token but not the instruction that creates the token itself. The IR is still valid but it's wasted. The source of the issue is coming from an old patch of yours: commit 7204cff0a121ebc770cf81f7f94679ae7324daae Author: David Majnemer <david.majnemer at

>Exceptions >All eh pads are grouped together regardless of their coldness and are part of the original function. There are outstanding issues with splitting eh pads if they reside in separate sections in the binary. This remains as part of future work. Can you elaborate more on the outstanding issues with splitting eh pads? From my dip into the unwind map in gcc_except_table the

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

+ CBL mailing list On Thu, Jun 27, 2019 at 11:08 AM Bill Wendling <isanbard at gmail.com> wrote: > [Adding the correct cfe-dev mailing list address.] > > On Thu, Jun 27, 2019 at 11:06 AM Bill Wendling <isanbard at gmail.com> wrote: > >> Now that ASM goto support has landed, Nick Desaulniers and I wrote up a >> document describing how to expand clang's

[Adding the correct cfe-dev mailing list address.] On Thu, Jun 27, 2019 at 11:06 AM Bill Wendling <isanbard at gmail.com> wrote: > Now that ASM goto support has landed, Nick Desaulniers and I wrote up a > document describing how to expand clang's implementation of ASM goto to > support output constraints. The work *should* be straight-forward, but as > always will need to