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>