> Please don't do that. Instead, please implement the TargetInstrInfo > branch analysis hooks so that the branch folding pass can do this. > Given info about branches, the pass already does various things to > optimize away many of the things that simplify cfg does. > > I'm planning several extensions to the pass, in particular to support > limited forms of "predication" (PPC's conditional return for sure, perhaps > some better cmov formation, etc). This may be generalizable for IA64/ARM, > but it depends on how much time I have to work on it. > > If there are specific cases like this where simplify cfg produces better > code than branch folding (with the hooks implemented) please file > bugzilla bugs to track them.The branch folding works after instruction selection, right? It looks strange to me that it will be able to convert a branch sequence into a select. IMHO this transformation can be better performed with a higher level representation.> Long term, I'd like to get the code generator to the point where running > the code generator doesn't modify from the input LLVM IR. Running > llvm->llvm passes breaks this property.I see that this is a desired property. If I recall correctly, you need this to remove the remaining annotations. Maybe llvm-gcc should run CFGSimplification. It would then compile "if (a) return 0; else return 1" into %tmp = seteq int %a, 0 %tmp1 = select bool %tmp, int 0, int 1 ret int %tmp1 Thanks, Rafael
On Thu, 2 Nov 2006, [UTF-8] Rafael Esp?ndola wrote:>> If there are specific cases like this where simplify cfg produces better >> code than branch folding (with the hooks implemented) please file >> bugzilla bugs to track them.> The branch folding works after instruction selection, right? It looks > strange to me that it will be able to convert a branch sequence into a > select. IMHO this transformation can be better performed with a higher > level representation.Yes, for this specific one, you're right. Simplifycfg is run multiple times in the standard llvm-gcc -Ox pipeline. We don't expect the code generator to magically produce optimal code for random .ll fragments, we expect that it has been optimized a bit first. :) If there is a specific example like this that isn't picked up by -O2, please let me know.>> Long term, I'd like to get the code generator to the point where running >> the code generator doesn't modify from the input LLVM IR. Running >> llvm->llvm passes breaks this property.> I see that this is a desired property. If I recall correctly, you need > this to remove the remaining annotations.The desire is driven more by my abstract notion of purity than anything practical :). However, it is needed to do a credible job of reoptimization in a JIT context, is needed if you want to codegen to multiple target variants at once, etc. These are all things that LLVM can and should do, but I personally don't have a short term driver for them.> Maybe llvm-gcc should run CFGSimplification. It would then compile "if > (a) return 0; else return 1" into > > %tmp = seteq int %a, 0 > %tmp1 = select bool %tmp, int 0, int 1 > ret int %tmp1Yep, it definitely does. Make sure you're using llvm-gcc4 and passing -O2 or higher. -Chris -- http://nondot.org/sabre/ http://llvm.org/
> > Maybe llvm-gcc should run CFGSimplification. It would then compile "if > > (a) return 0; else return 1" into > > > > %tmp = seteq int %a, 0 > > %tmp1 = select bool %tmp, int 0, int 1 > > ret int %tmp1 > > Yep, it definitely does. Make sure you're using llvm-gcc4 and passing -O2 > or higher.Strange. I have run it now on my desktop, and it produces very good code. I believe that the copy of llvm-gcc that I have in the laptop is very old. I will check that latter.> -ChrisThanks, Rafael