Re: [VTA, PR49310] O(n+m)-ish emit_notes

[Alexandre Oliva <aoliva at redhat dot com>]

On Sep 20, 2011, Jakub Jelinek <jakub@redhat.com> wrote:

> What worries me is that we suddenly emit far less than half of the
> previous call_site_value parameters:

Thanks for the measurements, I'll look into that.

> Those need to be emitted uncached

Would you please remind me why that is?  The reason totally escapes me.

> is it really necessary to add the cselib locations to the hash tables

Not sure, I'll have to think some more about it.

> can't it be postponed to start of vt_emit* phase

If my hunch is correct, no.  My concern is precisely that the equivalent
may cease to hold (say once we cross a val_reset within a loop), but
we'll keep on relying on it.

> And, do you do anything special for ENTRY_VALUEs?

Not really.  They should be at the end of the location list, so they're
only used as a last resort, but I haven't checked that the canonical
sort order does indeed push them to the very end, so they might be among
complex expressions, but not before REGs, MEMs and other VALUE
equivalences.

> suggests that the entry_value count increased for i686

Will look.

> On Mon, Sep 19, 2011 at 06:17:08PM -0300, Alexandre Oliva wrote:
>> /* Number of variable parts.  */
>> char n_var_parts;
>> 
>> -  /* True if this variable changed (any of its) cur_loc fields
>> -     during the current emit_notes_for_changes resp.
>> -     emit_notes_for_differences call.  */
>> -  bool cur_loc_changed;
>> +  /* What type of DV this is, according to enum onepart_enum.  */
>> +  onepart_enum_t onepart;

> Can't you use ENUM_BITFIELD (onepart_enum) onepart : 8; instead?

I don't think it will then be packed in the same word as n_var_parts.

>> if (GET_CODE (expr) == SET
>> && SET_DEST (expr) == loc
>> -	      && REGNO (loc) < FIRST_PSEUDO_REGISTER
>> -	      && TEST_HARD_REG_BIT (argument_reg_set, REGNO (loc))
>> && find_use_val (loc, mode, cui)
>> && GET_CODE (SET_SRC (expr)) != ASM_OPERANDS)
>> {

> Why the above?

That's what âstop relying on cselib-implied locsâ is about.

> Isn't it too expensive to enter it for all the registers,
> even when they aren't going to be used for argument passing nor needed
> explicitly for anything debug info related?

How do you know they're not going to be used?  If the register is
overwritten afterwards, the original expression still serves as an
alternate location for the VALUE.  If we took it from the cselib_val loc
list, we'd still have it (assuming it's right), but if we stop using
cselib locs (like this patch does), if we didn't record the equivalent
in the dataflow_set table, we'd lose it.

>> -	      item = gen_rtx_CONCAT (mode, item, DECL_RTL (dtemp));
>> +	      item = gen_rtx_CONCAT (mode, item, DECL_RTL_IF_SET (dtemp));

> Generating CONCAT with NULL second argument?

No, it is always set for dtemp, but DECL_RTL_IF_SET is cheaper because
it doesn't test whether it's set and call the setter.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer