Steven Bosscher wrote:
contains
subroutine sub(c)
character*10 c
end subroutine
end
produces as a GIMPLE dump:
sub (c, _c)
{
(void) 0;
}
where _c is strlen("Hi World!"). From a user perspective, it would be better
to hide _c for the debugger because it is not something that the user had in
the original program.
I think that _c should be emitted in DWARF, as an artificial parameter,
both for the sake of the debugger and for LTO. LTO is supposed to be
language-independent, which means that the information it reads in needs
to be sufficient to compute the types of things (as they will be at the
level of GIMPLE) without language hooks. It may be that this idea turns
out to be too idealistic, and that some language hooks are necessary to
interpret the DWARF, but I would hope to avoid that.
Similarly, LTO has to somehow deal with DECL_VALUE_EXPR and the debug
information that is produced from it. Is there already some provision
to handle this kind of trickery in LTO?
No, not yet.
but what would happen if LTO reads this in and re-constructs the type of "i"
from this information? I imagine it would lead to mis-matches of the GIMPLE
code that you read in, where "i" is a 1x100 array, and the re-constructed
variable "i" which would be a 10x10 2D array.
Has anyone working on LTO already thought of these challanges?
Yes, I've thought about these things -- but that doesn't mean I have
ready answers. I've been thinking first and foremost about C, and then
about C and C++.
Some of the same issues apply, but some don't. In C/C++, we don't
linearize the array type. I don't know if that's viable in gfortran or
not; is there a way to get the same performance in the middle end that
you currently get by doing this in the front end?
In the worst case, we will provide a separate type attribute in DWARF
giving the "GIMPLE type" of the variable. Then, that type would be the
linearized array. LTO would use the GIMPLE type attribute (if present)
when reconstructing the type.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
