[LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"

[edA-qa mort-ora-y]

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.