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: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

On 11/01/2012 09:10 AM, Richard Sandiford wrote:
Kenneth Zadeck <> writes:
I would like you to respond to at least point 1 of this email.   In it
there is code from the rtl level that was written twice, once for the
case when the size of the mode is less than the size of a HWI and once
for the case where the size of the mode is less that 2 HWIs.

my patch changes this to one instance of the code that works no matter
how large the data passed to it is.

you have made a specific requirement for wide int to be a template that
can be instantiated in several sizes, one for 1 HWI, one for 2 HWI.   I
would like to know how this particular fragment is to be rewritten in
this model?   It seems that I would have to retain the structure where
there is one version of the code for each size that the template is
I think richi's argument was that wide_int should be split into two.
There should be a "bare-metal" class that just has a length and HWIs,
and the main wide_int class should be an extension on top of that
that does things to a bit precision instead.  Presumably with some
template magic so that the length (number of HWIs) is a constant for:

typedef foo<2> double_int;

and a variable for wide_int (because in wide_int the length would be
the number of significant HWIs rather than the size of the underlying
array).  wide_int would also record the precision and apply it after
the full HWI operation.

So the wide_int class would still provide "as wide as we need" arithmetic,
as in your rtl patch.  I don't think he was objecting to that.

As is probably obvious, I don't agree FWIW.  It seems like an unnecessary
complication without any clear use.  Especially since the number of
significant HWIs in a wide_int isn't always going to be the same for
both operands to a binary operation, and it's not clear to me whether
that should be handled in the base class or wide_int.

There is a certain amount of surprise about all of this on my part. I thought that i was doing such a great thing by looking at the specific port that you are building to determine how to size these data structures. You would think from the response that i am getting that i had murdered some one.

do you think that when he gets around to reading the patch for simplify-rtx.c that he is going to object to this frag?
@@ -5179,13 +4815,11 @@ static rtx
simplify_immed_subreg (enum machine_mode outermode, rtx op,
enum machine_mode innermode, unsigned int byte)
- /* We support up to 512-bit values (for V8DFmode). */
enum {
- max_bitsize = 512,
value_bit = 8,
value_mask = (1 << value_bit) - 1
- unsigned char value[max_bitsize / value_bit];
+ unsigned char value [MAX_BITSIZE_MODE_ANY_MODE/value_bit];
int value_start;
int i;
int elem;

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