[llvm-dev] Parsing assembly into module while creating a function
Yichao Yu via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 9 20:31:43 PDT 2017
Hi,
We (julia) currently allow embedding LLVM IR as text in our code by
calling the LLVM IR parser when we encounters them in the middle of
emitting a function. This will pause the generation of the parent
function temporarily which will be resumed when the function from the
text IR are added to the module.
This approach works on version up to 5.0 but I just happenned to
notice today that it was broken a week ago by a NFC commit
(https://reviews.llvm.org/D38184). The change verifies the whole
module after parsing the assemble which catches the function that we
have left off temporarily. I see that there's the new UpgradeDebugInfo
argument added to the parsing functions but it is documented as only
"for use inside the LLVM testuite!" so I'm hesitation before using
it...
It should be possible to work around this issue on our side but I'd
like to ask here first whether this side effect is desired? A few
things that make me think this is not really the expected behavior,
1. It is allowed (AFAICT) to start emitting another function before
finishing all other functions. It seems that `parseAssemblyInto`
should allow doing something similar.
2. It is not documented that `parseAssemblyInto` now requires a
valid/completed module as its input. Such limitation can be lifted
with the `UpgradeDebugInfo` parameter but that doesn't sound like the
right option to get something closed to the old behavior.
The solutions I can come up with right now,
1. Resume the old semantics of `parseAssemblyInto` (i.e. allow
incomplete functions in the module). All other solutions should
document the new requirement.
2. Switch away from `parseAssemblyInto` in our code. (This makes
`parseAssemblyInto` less useful so hopefully not...)
3. Use `UpgradeDebugInfo = false`. We don't have any debug info for
the embedded LLVM code so this should work for us. Still given the
description of the argument it doesn't sound like the right
solution...
Any opinion on which one of the solution (or any other ones) is the right one?
Thanks,
Yichao Yu
More information about the llvm-dev
mailing list