llvm dev - Apr 2013 - [LLVMdev] Any value in pre-simplifying the DAG?

I've been adding some new flow statements to my compiler and realize the
easiest/laziest way to produce the DAG is just to store a flow variable
and end blocks with a "switch" branch. It appears the optimizers do a
fine job of unwinding the nonsense, reducing the conditions, and even
expanding the trailing paths.

For example, I terminate my blocks with a logical switch like this:
	switch return_path, next_block
		cleanup, except_block
		break, loop_block
		return, return_block
		rethrow, except_block

In most cases I'd say only 1-2 of the cases are actually possible
(return_path cannot be the other values). Is there any value in me
attempting to produce a cleaner DAG to pass to the optimizer, or would I
just be duplicating effort the passes will end up doing anyway?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130417/70babfbf/attachment.sig>

Hi edA-qa mort-ora-y,

On 17/04/13 21:27, edA-qa mort-ora-y wrote:
> I've been adding some new flow statements to my compiler and realize
the
> easiest/laziest way to produce the DAG is just to store a flow variable
> and end blocks with a "switch" branch. It appears the optimizers
do a
> fine job of unwinding the nonsense, reducing the conditions, and even
> expanding the trailing paths.
>
> For example, I terminate my blocks with a logical switch like this:
> 	switch return_path, next_block
> 		cleanup, except_block
> 		break, loop_block
> 		return, return_block
> 		rethrow, except_block
>
> In most cases I'd say only 1-2 of the cases are actually possible
> (return_path cannot be the other values). Is there any value in me
> attempting to produce a cleaner DAG to pass to the optimizer, or would I
> just be duplicating effort the passes will end up doing anyway?
does the front-end have special knowledge about the possible values?  If the
front-end can do simplifications that the optimizers can't possibly do
because
the required information can't be logically deduced from the IR, then the
front
end will have to do it.

If the front-end can do the simplifications simply and cheaply, then it may be a
win to have the front-end do it, since significantly reducing the complexity of
the initial CFG may speed up LLVM's optimizers.

Otherwise, if LLVM is doing a good job, you might as well let it do the work.

Ciao, Duncan.

On 18/04/13 09:07, Duncan Sands wrote:
> If the front-end can do the simplifications simply and cheaply, then it
> may be a
> win to have the front-end do it, since significantly reducing the
> complexity of
> the initial CFG may speed up LLVM's optimizers.
This is my primary concern now is speed. LLVM is doing a nicer job at
simplifying than I could, but I think the endless repetition of these
switches is likely slowing down the process. Most of the knowledge is
completely transparent thus there's nothing really more that I know at
the high level.

I'll do the really cheap things and cleanup what I can to reduce the
size, but otherwise I'll just let LLVM do the hard work. ;)


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130418/42678b2c/attachment.sig>