This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Status Report (2004-03-09)
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org,gcc-patches at gcc dot gnu dot org
- Date: Fri, 19 Mar 2004 00:36:33 +0100
- Subject: Re: GCC Status Report (2004-03-09)
- References: <200403091809.i29I9P04020607@sirius.codesourcery.com> <200403181927.00513.ebotcazou@libertysurf.fr> <4059EE8A.4060407@codesourcery.com>
> We could only zero out the "holes" between the fields. That would be
> slower than zeroing the hole thing at once, but usually not much,
> especially since memzero will be inlined for small chunks of memory.
This can probably be awful in certain cases too (mix const/non-const,
bitfields, packed fields, ...). And this would defeat the clrstr patterns,
on x86 for example.
> We could also disable the use of RTX_UNCHANGING_P in alias.c.
Could this be done somewhat selectively?
> We could make RTX_UNCHANGING_P a tri-state (with a don't-know option),
> which would probably be best. That would allow us to keep most of the
> optimizations, but it's probably a lot more work and more invasive.
>
> We have to pessimize something because we have a poorly-designed feature
> (i.e., one with an incomplete specification) that results in generating
> wrong code.
Unfortunately, yes, this appears to be unavoidable.
> What solution do you dislike least?
Nice formulation :-) Richard (rth) even proposed to disable entirely
RTX_UNCHANGING_P in 3.4/3.5. I personally think the 3.3.x code is cleaner
(albeit probably not 100% safe).
> How about the idea above of just zeroing the holes?
If you're fine with the blockage approach...
--
Eric Botcazou