This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] fix arm neon ICE by widening tree_type's precision field
On Tue, Jun 9, 2009 at 11:40 AM, Steven Bosscher<firstname.lastname@example.org> wrote:
> On Tue, Jun 9, 2009 at 4:54 PM, Nathan Froyd<email@example.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?
I don't like moving all lang-specific type flags to base. There are some
bits in base used for non-generic things already, so moving a bit like
user_align there should be following existing practice, like
saturating_flag which is type-only as well (it could even
re-use like default_def_flag).
> P.S. please fix your reply-to field! ?;-)