This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


! /* 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]