This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: IPA merge 4: SSA inliner
Jan Hubicka wrote on 12/20/06 10:44:
In the inliner producing invalid gimple by substituting constant
somewhere without properly folding in. If you check changelogs on
tree-inline for past few months, you can see there was several
bugfixes into this area. I didn't run across any for a while, so
things seems to've improved, perhaps in longer term a little more
sharing with tree-ccp would help (like we have in RTL backend
validate_replace infrastructure that does replacement right).
Maybe we can just use the substitute_and_fold? Though that would
involve a second pass.
The problem is that the GIMPLE statement looks like: struct = fun();
but the semantic of return slot is fun(&struct) with function fun
writing result to *struct. So there is implicit address taking in
the function call. We don't represent this for alias analysis and at
single function level this would only reduce code quality. We know
that FUN won't do anything with the address except for *struct =
something...
Oh, that. Yes, I remember now.
We initialize proper DEF_STMT in copy_bb. Perhaps /* Do not set
DEF_STMT yet as statement is not copied yet. Leave the setting to
copy_bb. */
>
Yeah, that comment is a good idea.
If you have something like
fun() { if (...) return 5; }
and you inline it into
ssa_name = fun();
We end up:
if (...) mapped_result_decl = 5; ssa_name = mapped_result_decl;
that would be invalid SSA form if mapped_result_decl was SSA_NAME. I
simply force it to be a variable.
>
Ah, OK.
Careful here. This has disappeared. You *could* use
mark_symbols_for_renaming, but that only works if the symbols you
want to rename are not wrapped in SSA names in the operands. What
symbols are you trying to mark for renaming here?
I want to basically build VOPS for static vairables and SSA for
variables where I decided to strip down the SSA_NAME for reasons
discussed above.
>
OK, then I think you should be safe.
We can drop it from initial patch and I will double check how things
behave now before enabling inliner on SSA as this is executed
multiple times in fortran testsuite.
OK.
! /* FIXME: rewriting random variables in SSA form is
going ! to cause missoptimizations once we start optimizing. !
I don't understand this. Why would we have mis-optimizations? Show
me sample code?
When you have overlapping life range:
Oh! But that's not what your comment says :) Better change the comment
then.
I'm fine with the patch then.