llvm dev - Jun 2019 - IRBuilder input debug

Dear Developers,

I would like get detailed info if verification of the intermediate
representation fails.
Currently I am using IRBuilder to create a module, and I encountered an
error, which I cannot trace back to the IRBuilder related call, which
caused the error:
"Instruction does not dominate all uses!
%14 = load i32, i32* @r6 <https://github.com/r6>
%11 = trunc i32 %14 to i8
LLVM ERROR: Broken function found, compilation aborted!"

This description is too losely specified for me to know, where the causing
code is located. Getting 20 lines instead of 2 would help. Getting
additional info of the broken function could also help. How can this be
solved?

Best regards,
Norbert Dajka
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190612/edd2a4ec/attachment.html>

Hi Norbert,

On Wed, 12 Jun 2019 at 23:53, Winter Claus via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Currently I am using IRBuilder to create a module, and I encountered an
error, which I cannot trace back to the IRBuilder related call, which caused the
error:
> "Instruction does not dominate all uses!
> %14 = load i32, i32* @r6
> %11 = trunc i32 %14 to i8
> LLVM ERROR: Broken function found, compilation aborted!"
>
> This description is too losely specified for me to know, where the causing
code is located. Getting 20 lines instead of 2 would help. Getting additional
info of the broken function could also help. How can this be solved?
This looks like an error in the Verifier. I often find them a bit
terse too, but I don't think there's a command-line option to
automatically be more verbose on an error. I tend to set a breakpoint
in "CheckFailed" and go up a few stack levels. That usually lets you
dump the function or module that's causing problems.

Alternatively, you might dump your functions just after creating them
and look for truncs & loads with those operands.

Cheers.

Tim.

One problem I see with the IR verifier's output is that it does not display
the functon(s) in which the error occurs.

A common error on my part is to reference a value generated in one
function, from a different function.  (This may seem strange, but it can
happen because I cache the LLVM value of evaluating an expression in some
required circumstances, and I need to explicitly purge this cached value if
I know that I need to evaluate an expression in two different contexts.)
When this happens I need to grep the IR to try to figure out which
functions are involved.



On Thu, Jun 13, 2019 at 8:09 AM Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Norbert,
>
> On Wed, 12 Jun 2019 at 23:53, Winter Claus via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Currently I am using IRBuilder to create a module, and I encountered
an
> error, which I cannot trace back to the IRBuilder related call, which
> caused the error:
> > "Instruction does not dominate all uses!
> > %14 = load i32, i32* @r6
> > %11 = trunc i32 %14 to i8
> > LLVM ERROR: Broken function found, compilation aborted!"
> >
> > This description is too losely specified for me to know, where the
> causing code is located. Getting 20 lines instead of 2 would help. Getting
> additional info of the broken function could also help. How can this be
> solved?
>
> This looks like an error in the Verifier. I often find them a bit
> terse too, but I don't think there's a command-line option to
> automatically be more verbose on an error. I tend to set a breakpoint
> in "CheckFailed" and go up a few stack levels. That usually lets
you
> dump the function or module that's causing problems.
>
> Alternatively, you might dump your functions just after creating them
> and look for truncs & loads with those operands.
>
> Cheers.
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190613/d0aad237/attachment.html>