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: [PATCH] Fix the one entry mem{{,p}cpy,move,set} optimization aliasing issues (PR middle-end/29272)


Richard Guenther wrote:

I think this idea is reasonable.  Unfortunately, I'd expect one of the
cases where this optimization to be most useful to be copying into
heap-allocated memory, but correctness trumps optimization...

I agree. Looking at the C standard I see no way to make the pool allocator in the PR conforming. If not refering to dynamic typing of storage as C++ defines (which I believe now should be the model the middle-end uses).

I added some comments to the PR 29286 (about placement new).


I agree that since C doesn't have a clear model of object lifetimes in this respect. I'm not sure how to write a fully conforming malloc alternative, in pure C, allocating memory out of a giant char array, for example. I think we just have to accept that the standards don't really address these issues.

So, I think we have to punt -- when we can't tell what's happening to dynamically allocated memory, we have to assume its dynamic type is changing, and drop our type-based aliasing assumptions. I don't think it's a good idea to try to intuit too much about the actual dynamic type of memory based on operator new/malloc/memcpy; even if we could work out clear rules, I'm not at all convinced that the users would agree with them.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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