On 15 September 2015 at 14:18, Richard Biener <richard.guent...@gmail.com> wrote: > Of course this boils down to "uses" of a VAR_DECL using the shared tree > node. On GIMPLE some stmt kinds have separate locations for each operand > (PHI nodes), on GENERIC we'd have to invent a no-op expr tree code to > wrap such uses to be able to give them distinct locations (can't use sth > existing as frontends would need to ignore them in a different way than say > NOP_EXPRs or NON_LVALUE_EXPRs). >
The problem with that approach (besides the waste of memory implied by a whole tree node just to store one location_t) is keeping those wrappers in place while making them transparent for most of the compiler. According to Arnaud, folding made this approach infeasible: https://gcc.gnu.org/ml/gcc-patches/2012-09/msg01222.html The other two alternatives are to store the location of the operands on the expressions themselves or to store them as on-the-side data-structure, but they come with their own drawbacks. I was initially more in favour of the wrapper solution, but after dealing with NOP_EXPRs, having to deal also with LOC_EXPR would be a nightmare (as you say, they will have to be ignored in a different way). The other alternatives seem less invasive and the problems mentioned here https://gcc.gnu.org/ml/gcc-patches/2012-11/msg00164.html do not seem as serious as I thought (passing down the location of the operand is becoming the norm anyway). Cheers, Manuel.