On 09/15/2015 06:54 AM, Manuel López-Ibáñez wrote:
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).
I suspect any on-the-side data structure to handle this is ultimately
doomed to failure. Storing the location info for the operands in the
expression means that anything that modifies an operand would have to
have access to the expression so that location information could be
updated. Ugh.
As painful as it will be, the right way is to stop using DECL nodes like
this and instead be using another node that isn't shared. That allows
atttaching location information. David and I kicked this around before
he posted his patch and didn't come up with anything better IIRC.
These wrapper nodes are definitely going to get in the way of folders
and all kinds of things. So it's not something that's going to be easy
to add without digging into and modifying a lot of code.
I've always considered this a wart, but fixing that wart hasn't seemed
worth the effort until recently.
Jeff
