Re: [PATCH 0/4] bitpos expansion summary reloaded

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Tue, 23 Oct 2012 03:34:38 +0200, Jan Kratochvil wrote:
> On Mon, 22 Oct 2012 22:45:35 +0200, Tom Tromey wrote:
> > The reason I ask is that I'm concerned about our ability to maintain
> > this change properly, and I wonder if this would be a cheap way to
> > handle the more mechanical aspects.
> 
> Cheap for future reviewing.  But more expensive for the initial change.

To make clear what is the problem here:

Primarily I admit I did not know until recently there is -Wconversion at all.

The most easy would be to extend to 64-bit any automvaribles handling
TYPE_LENGTH (and some similar fields also being extended to 64-bit).
But this would include 64-bit lengths of scalar types which has been
considered as both performance wasteful and needless work to change them all.

The most difficult work on this patch has been (for me) to always judge
whether a type at that place of code has to be always scalar or not.

It is only about the autovariables as TYPE_LENGTH itself of scalar types has
to be 64-bit already (because that struct type->length field has to be 64-bit
for struct/array types).

IMO we could extend 64-bit length handling everywhere and nothing happens.
But I always expected other maintainers will not accept that as it may have
performance impact on various non-x86* slow 32-bit host GDB platforms.

IMO there are more serious (=algorighmic complexity ones) performance problems
of GDB than some worse constant complexity of 64-bit types.

I do not see how to easily measure the performance impact without implementing
the full 64-bit extension first (but I also believe more work could be
invested in fixing the more serious performance problems than trying to
micro-optimize this 32-bit vs. 64-bit autovariables).

Maybe there are no concerns about extending even scalars to 64-bit?


Regards,
Jan