submit [PATCH] SimplifyCFG for code review

Ye, Mei Mei.Ye at amd.com
Fri Jun 21 10:40:37 PDT 2013


What I mean is that there is usually no reliable way to prove whether an optimization is good for all architectures in all different implementations.
What I take from this discussion is that optimization works should be pushed down to code gen whenever possible, which is fine with me. But it will be good to know that this is common guideline in this community.

-Mei


From: Renato Golin [mailto:renato.golin at linaro.org]
Sent: Friday, June 21, 2013 10:27 AM
To: Ye, Mei
Cc: Evan Cheng; llvm-commits at cs.uiuc.edu
Subject: Re: submit [PATCH] SimplifyCFG for code review

On 21 June 2013 18:09, Ye, Mei <Mei.Ye at amd.com<mailto:Mei.Ye at amd.com>> wrote:
So the question is:  if there is a requirement of proof, is there a standard on which architecture with what kind of machine configurations?

You took of part my comment a bit too literally, and not the most important part, I'm afraid. It's not a matter of running "a" set of benchmarks on "a" list of configurations that will "prove" your patch is good, it's a matter of thinking how we can apply the transformation you need into LLVM without breaking unknown code on unknown targets.

As Evan said, you probably implemented the transformation in the wrong place, and what we have to do now is to understand what is the best place to put it, not run benchmarks.

Also, it should be specific to your target unless it benefits the majority of targets (here is where things get confusing), and even that, should be done slowly. If you implement in the back-end, or close to it, than it'll be easier to make it specific. If not, you'll have to create a compiler flag and leave it disabled by default. By Evan's comments, I guess you'll be safer with the former option.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130621/cfd7bad5/attachment.html>


More information about the llvm-commits mailing list