On Sep 13, 2010, at 1:15 AM, Duncan Sands wrote:>> I compiled with "llvm-gcc -emit-llvm test.c -S -o test.ll". Attached to this >> message are the source and the resulting ll output. > > compile with optimization. The llvm-gcc front-end "cheats" and stores/loads all > values to/from memory, avoiding the need to construct phi nodes; instead it lets > the optimizers do that. For what it's worth the dragonegg plugin produces phi > nodes directly, even at -O0. I don't know what clang does.If you're talking about variables, clang emits stores and loads, of course. C/C++ variables specify their semantics in terms of objects in memory; SSA conversion is an optimization which does break (obviously invalid) programs. Any attempt by the frontend to emit variables in true SSA form is just duplicating this optimization — in the case of dragonegg, because the SSA conversion is implicit in how gcc creates the IR it lowers from. John.
On Sep 13, 2010, at 10:46 AM, John McCall wrote:> On Sep 13, 2010, at 1:15 AM, Duncan Sands wrote: >>> I compiled with "llvm-gcc -emit-llvm test.c -S -o test.ll". >>> Attached to this >>> message are the source and the resulting ll output. >> >> compile with optimization. The llvm-gcc front-end "cheats" and >> stores/loads all >> values to/from memory, avoiding the need to construct phi nodes; >> instead it lets >> the optimizers do that. For what it's worth the dragonegg plugin >> produces phi >> nodes directly, even at -O0. I don't know what clang does. > > If you're talking about variables, clang emits stores and loads, of > course. C/C++ > variables specify their semantics in terms of objects in memory; > SSA conversion > is an optimization which does break (obviously invalid) programs. > Any attempt > by the frontend to emit variables in true SSA form is just > duplicating this > optimization — in the case of dragonegg, because the SSA conversion is > implicit in how gcc creates the IR it lowers from.Makes sense. However, grep'ing on CreatePHI in clang's CodeGen module I see several places where clang's 'front-end' is doing this. What is the rational for that? - Fariborz> > > John. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Sep 13, 2010, at 10:58 AM, Fariborz Jahanian wrote:> On Sep 13, 2010, at 10:46 AM, John McCall wrote: >> On Sep 13, 2010, at 1:15 AM, Duncan Sands wrote: >>>> I compiled with "llvm-gcc -emit-llvm test.c -S -o test.ll". Attached to this >>>> message are the source and the resulting ll output. >>> >>> compile with optimization. The llvm-gcc front-end "cheats" and stores/loads all >>> values to/from memory, avoiding the need to construct phi nodes; instead it lets >>> the optimizers do that. For what it's worth the dragonegg plugin produces phi >>> nodes directly, even at -O0. I don't know what clang does. >> >> If you're talking about variables, clang emits stores and loads, of course. C/C++ >> variables specify their semantics in terms of objects in memory; SSA conversion >> is an optimization which does break (obviously invalid) programs. Any attempt >> by the frontend to emit variables in true SSA form is just duplicating this >> optimization — in the case of dragonegg, because the SSA conversion is >> implicit in how gcc creates the IR it lowers from. > > Makes sense. However, grep'ing on CreatePHI in clang's CodeGen module I see several > places where clang's 'front-end' is doing this. What is the rational for that?We do emit phis when the semantics aren't defined in terms of memory, e.g. with expressions that have multiple paths of control flow (like the conditional operator or null-checked derived-to-base conversions). John.