This is the mail archive of the gcc-patches@gcc.gnu.org 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 Status Report (2004-03-09)


Eric Botcazou wrote:

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.


Well, it's only awful if you have a structure with a really annoying initializer (like, they initialized every other field). If they initialized the first part of the structure, but not the end, or the first few elements of an array, this approach isn't bad at all. So, in practice, I bet it wouldn't be much worse for most real code.

We could also disable the use of RTX_UNCHANGING_P in alias.c.



Could this be done somewhat selectively?


I dunno. That's why I suggested making it a tri-state; then, the selectivity comes from the places where you said "don't know".

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...

I'm OK with the blockage approach. We can try to do better for 3.4.1, perhaps.

Would you go ahead and check that in, and close the PRs?

Thank you for all your help with this issue; this was a very important one to fix.

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com



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