From: Steven Bosscher <stevenb.gcc@gmail.com>
To: gcc-patches@gcc.gnu.org, richard.guenther@gmail.com,
stevenb.gcc@gmail.com, Nathan Froyd <froydnj@codesourcery.com>
Subject: Re: [PATCH] fix arm neon ICE by widening tree_type's precision field
Date: Tue, 09 Jun 2009 15:40:00 -0000 [thread overview]
Message-ID: <571f6b510906090840m3848d987g5d89c5ad6cd6836a@mail.gmail.com> (raw)
In-Reply-To: <20090609145403.GZ21107@codesourcery.com>
On Tue, Jun 9, 2009 at 4:54 PM, Nathan Froyd<froydnj@codesourcery.com> wrote:
>> Actually, what about moving all 7 language specific fields to base? ;-)
>> We have 23 spare bits in base and 0 in type, that would even the field
>> a bit.
>
> Ah, OK. Yes, that's rather obvious.
>
> I don't see how this proposal is immune to Steven's complaint that
> type-specific bits are moving into the generic bits.
It's not a complaint, it's a comment. I just think it would be best
to keep the bits that are only used for types in the structs specific
for type nodes.
>I think it is less
> gross, though. I don't like Steven's approach of just making type
> bigger; I think making all architectures pay for the needs of one
> architecture is poor form, especially when there are other approaches
> that avoid the cost.
Don't put words in my mouth that I did not say, thank you very much.
I did not propose "just making type bigger". I just said I dislike
your argument that you didn't know or understand the data structures
very well, and therefore you take the easy way out (same as what
happened with the loop index promotion pass). It leads to messy code
in the long run and that is all I am trying to avoid. There is
pragmatism, and there is quick and dirty hacks. The former is OK, the
latter is not.
To quote what we said, specifically: You said: "> - I personally don't
know which bits could be safely moved," and I replied "Probably no-one
knows. That's why you have a salary: Gives you time to figure it out
;-)". This does not say anywhere "please just make type bigger". It
says: "Try harder, figure out which bits could be safely moved."
And BTW, your approach also comes with a cost: a few mor patches like
yours and we'll be back to square one with incomprehensible tree data
structures. You seem to think that what is cheap and works now is also
cheap and will also work in the long run. Clearly you haven't been
around long enough to see the what mess that results in. One little
bit is a bike shed now but a problem, say, 5 years from now when
tree_code is one bit too small for someone's next crazy idea...
> Richard, Steven, do either of you have complaints about moving the
> lang_flag_* fields from type into base (renaming them into
> type_lang_flag_*) to free up space instead of moving packed_flag?
I don't like it but there doesn't seem to be a better alternative. All
the TYPE_LANG_FLAG_x flags are in use, and so are all other bits (I
actually checked that). Someone already suspiciously squeezed out a
bit from TYPE_MODE.
So if moving the type.lang_flag bits to tree_base is what you end up
doing, can you please also give one bit back to TYPE_MODE so that it
is 8 bit again just like all other ENUM_BITFIELD(machine_mode) (only
recog has 16 bits for machine mode -- will we ever need >256 modes?),
and reshuffle the bitfields a bit, to make the access to the
most-often used fields cheaper?
Ciao!
Steven
P.S. please fix your reply-to field! ;-)
next prev parent reply other threads:[~2009-06-09 15:40 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-08 15:32 Nathan Froyd
2009-06-08 17:11 ` Richard Guenther
2009-06-08 18:04 ` Paolo Bonzini
2009-06-08 20:28 ` Nathan Froyd
2009-06-08 20:32 ` Steven Bosscher
2009-06-09 6:36 ` Paolo Bonzini
2009-06-09 14:54 ` Nathan Froyd
2009-06-09 15:00 ` Richard Guenther
2009-06-09 15:07 ` Richard Guenther
2009-06-09 15:44 ` Steven Bosscher
2009-06-10 2:50 ` Eric Botcazou
2009-06-09 15:40 ` Steven Bosscher [this message]
2009-06-09 15:53 ` Richard Guenther
2009-06-09 16:31 ` Nathan Froyd
2009-06-09 16:34 ` Richard Guenther
2009-06-09 16:36 ` Diego Novillo
2009-06-09 17:30 ` Paolo Bonzini
2010-07-28 19:01 ` [4.5 regression] C++ ignores some aligned attributes (Re: [PATCH] fix arm neon ICE by widening tree_type's precision field) Ulrich Weigand
2010-07-28 19:40 ` Richard Guenther
2010-07-29 12:29 ` [4.5 regression] C++ ignores some aligned attributes (Re: [PATCH] fix arm neon ICE by widening tree_type's precision field Ulrich Weigand
2010-07-28 22:07 ` [PATCH] [4.5 regression] C++ ignores some aligned attributes Ulrich Weigand
2010-07-30 16:00 ` Ulrich Weigand
2010-07-30 16:22 ` Richard Guenther
2010-07-30 16:22 ` Ulrich Weigand
2010-07-31 17:45 ` Eric Botcazou
2010-07-31 19:38 ` Ulrich Weigand
2010-08-04 14:03 ` Paul Brook
2010-08-04 14:19 ` Ulrich Weigand
2010-08-04 14:27 ` Mark Mitchell
2010-08-04 15:04 ` Paul Brook
2010-08-04 16:42 ` Ulrich Weigand
2010-08-04 15:33 ` Martin Sebor
2010-08-04 15:47 ` Mark Mitchell
2010-08-05 9:02 ` Martin Sebor
2009-06-08 19:40 ` [PATCH] fix arm neon ICE by widening tree_type's precision field Joseph S. Myers
2009-06-08 19:52 ` Daniel Jacobowitz
2009-06-08 20:12 ` Andrew Pinski
2009-06-08 20:20 ` Jakub Jelinek
2009-06-08 20:33 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=571f6b510906090840m3848d987g5d89c5ad6cd6836a@mail.gmail.com \
--to=stevenb.gcc@gmail.com \
--cc=froydnj@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).