llvm dev - Nov 2013 - [LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"

I've having a bit of a problem generating output that doesn't result in
the "Instruction does not dominate all uses!". In my code it relates
to
exception handling and how I generate the blocks. I understand exactly
why I get the message, but I'm unsure of how I can structure things to
avoid the problem.

In a rough pseudo-code, my blocks look like this:

entry:
	store 0, return_path
	result = invoke func to defer_block unwind landing

landing:
	landingpad
	store 1, return_path
	br defer_block

defer_block:
	stuff
	switch return_path, next_step [
		0, next_step
		1, rethrow
	]

next_step:
	val = load result  ; error here


Structually the `next_step` has multiple preceding blocks, one of which
doesnt' define `result`. That results in the error. However, based on
the switching value `return_path` there is no way we can arrive at
`next_step` unless result has actually been set. Is there some way I can
tell LLVM this? Somehow just say "trust me", on the understanding that
it would be totally undefined if we arrive at `next_step` without result
being set?

I know one generic approach, which I've started implementing, but I'm
not sure it is a good solution. Instead of using results directly I
always store in a local variable:

	result = alloca result_type
	tmp = invoke func to store_block unwind landing

store_block:
	store tmp, result
	br defer_block

...

next_step:
	val = load result

Here result would just be undefined if we arrive at `next_step` without
having gone through `store_block`. It works, but my guess is that I'm
hiding some valuable information from the optimizers.


-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

You could try placing a phi node at "defer_block" with incoming value
"result"
when the incoming block is "entry", and do the same for
"null" and
"landing".
Then, instead of loading "result", you load the value given by the
newly
created phi. That seems like the easiest solution.

H.


On Sun, Nov 3, 2013 at 4:21 AM, edA-qa mort-ora-y <eda-qa at
disemia.com>wrote:
> I've having a bit of a problem generating output that doesn't
result in
> the "Instruction does not dominate all uses!". In my code it
relates to
> exception handling and how I generate the blocks. I understand exactly
> why I get the message, but I'm unsure of how I can structure things to
> avoid the problem.
>
> In a rough pseudo-code, my blocks look like this:
>
> entry:
>         store 0, return_path
>         result = invoke func to defer_block unwind landing
>
> landing:
>         landingpad
>         store 1, return_path
>         br defer_block
>
> defer_block:
>         stuff
>         switch return_path, next_step [
>                 0, next_step
>                 1, rethrow
>         ]
>
> next_step:
>         val = load result  ; error here
>
>
> Structually the `next_step` has multiple preceding blocks, one of which
> doesnt' define `result`. That results in the error. However, based on
> the switching value `return_path` there is no way we can arrive at
> `next_step` unless result has actually been set. Is there some way I can
> tell LLVM this? Somehow just say "trust me", on the understanding
that
> it would be totally undefined if we arrive at `next_step` without result
> being set?
>
> I know one generic approach, which I've started implementing, but
I'm
> not sure it is a good solution. Instead of using results directly I
> always store in a local variable:
>
>         result = alloca result_type
>         tmp = invoke func to store_block unwind landing
>
> store_block:
>         store tmp, result
>         br defer_block
>
> ...
>
> next_step:
>         val = load result
>
> Here result would just be undefined if we arrive at `next_step` without
> having gone through `store_block`. It works, but my guess is that I'm
> hiding some valuable information from the optimizers.
>
>
> --
> edA-qa mort-ora-y
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> Sign: Please digitally sign your emails.
> Encrypt: I'm also happy to receive encrypted mail.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131103/3b52d325/attachment.html>