* tree-SSA and indirect references. @ 2004-01-20 0:31 Jan Hubicka 2004-01-20 0:59 ` Richard Henderson 0 siblings, 1 reply; 7+ messages in thread From: Jan Hubicka @ 2004-01-20 0:31 UTC (permalink / raw) To: gcc, law, rth Hi, I re-tested my patch to elliminate addressof and noticed that there is still noticeable regression on Gerald's testcase (but not on GCC components test). I modified addressof code to output variables that were kept in registers and was looking back for the dumps. There seems to be common pattern of: vara=(type *)&varb; varc=*vara; this is common for small aggregate casts that can stay in registers after compiling. What is our strategy to deal with this? Is the testcase gimple at first case and would be valid to turn it into varc=(type)varb for aggregates? NOP expander seems to do right thing, but I am not sure it is best idea. Honza ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: tree-SSA and indirect references. 2004-01-20 0:31 tree-SSA and indirect references Jan Hubicka @ 2004-01-20 0:59 ` Richard Henderson 2004-01-20 9:50 ` Jan Hubicka 0 siblings, 1 reply; 7+ messages in thread From: Richard Henderson @ 2004-01-20 0:59 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc, law On Tue, Jan 20, 2004 at 01:31:56AM +0100, Jan Hubicka wrote: > vara=(type *)&varb; > varc=*vara; > > this is common for small aggregate casts that can stay in registers > after compiling. What is our strategy to deal with this? I don't know. I think it depends what the set of all these types are. r~ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: tree-SSA and indirect references. 2004-01-20 0:59 ` Richard Henderson @ 2004-01-20 9:50 ` Jan Hubicka 2004-01-20 10:21 ` Richard Henderson 0 siblings, 1 reply; 7+ messages in thread From: Jan Hubicka @ 2004-01-20 9:50 UTC (permalink / raw) To: Richard Henderson, Jan Hubicka, gcc, law > On Tue, Jan 20, 2004 at 01:31:56AM +0100, Jan Hubicka wrote: > > vara=(type *)&varb; > > varc=*vara; > > > > this is common for small aggregate casts that can stay in registers > > after compiling. What is our strategy to deal with this? > > I don't know. I think it depends what the set of all these types are. In the case of Gerald's testcase these are different classes inherited from each other. They are iterators so the structures are small, I think containing just one field. Honza > > > r~ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: tree-SSA and indirect references. 2004-01-20 9:50 ` Jan Hubicka @ 2004-01-20 10:21 ` Richard Henderson 2004-01-20 14:25 ` Jan Hubicka 0 siblings, 1 reply; 7+ messages in thread From: Richard Henderson @ 2004-01-20 10:21 UTC (permalink / raw) To: Jan Hubicka; +Cc: Jan Hubicka, gcc, law, Jason Merrill On Tue, Jan 20, 2004 at 10:50:13AM +0100, Jan Hubicka wrote: > > On Tue, Jan 20, 2004 at 01:31:56AM +0100, Jan Hubicka wrote: > > > vara=(type *)&varb; > > > varc=*vara; > > In the case of Gerald's testcase these are different classes inherited > from each other. Would you please be concrete, draw the diagram and show the members? My guess is that the best way to fix this is to change how the C++ front end implements inheritence. At present, as you can see, the front end takes the address of the base, casts, and then dereferences. From the point of view of GIMPLE, it would be much better to have this appear to be nested structures. (The only exception will be for virtual bases, but I can see from the above that that is not at issue for this test case.) I have no idea how easy or difficult such a change might be. Jason or Mark, perhaps you could comment? r~ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: tree-SSA and indirect references. 2004-01-20 10:21 ` Richard Henderson @ 2004-01-20 14:25 ` Jan Hubicka 2004-01-20 16:57 ` Andrew Pinski 0 siblings, 1 reply; 7+ messages in thread From: Jan Hubicka @ 2004-01-20 14:25 UTC (permalink / raw) To: Richard Henderson, Jan Hubicka, Jan Hubicka, gcc, law, Jason Merrill > On Tue, Jan 20, 2004 at 10:50:13AM +0100, Jan Hubicka wrote: > > > On Tue, Jan 20, 2004 at 01:31:56AM +0100, Jan Hubicka wrote: > > > > vara=(type *)&varb; > > > > varc=*vara; > > > > In the case of Gerald's testcase these are different classes inherited > > from each other. > > Would you please be concrete, draw the diagram and show the members? > > My guess is that the best way to fix this is to change how the C++ > front end implements inheritence. > > At present, as you can see, the front end takes the address of the > base, casts, and then dereferences. From the point of view of GIMPLE, > it would be much better to have this appear to be nested structures. > (The only exception will be for virtual bases, but I can see from the > above that that is not at issue for this test case.) > > I have no idea how easy or difficult such a change might be. Jason > or Mark, perhaps you could comment? Actually the casts don't have to be very complex. See for instance: <D175450>_4 = (short unsigned int * const *)&__first; T.14797_7 = *<D175450>_4; <D175454>_9 = (short unsigned int * const *)&__last; T.14799_12 = *<D175454>_9; these two are operands of template: void std::fill(_ForwardIter, _ForwardIter, const _Tp&) [with _ForwardIter = __gnu_cxx::__normal_iterator<short unsigned int*, std::vector<short unsigned int, std::allocator<short unsigned int> > >, _Tp = short unsigned int] (__first, __last, __value) so if I read it right, they shall differ only in constantness. The other cass I saw were just same case of instantiation of template to aggregate I think. Honza > > > r~ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: tree-SSA and indirect references. 2004-01-20 14:25 ` Jan Hubicka @ 2004-01-20 16:57 ` Andrew Pinski 2004-01-20 18:15 ` Richard Henderson 0 siblings, 1 reply; 7+ messages in thread From: Andrew Pinski @ 2004-01-20 16:57 UTC (permalink / raw) To: Jan Hubicka Cc: Jason Merrill, law, gcc, Richard Henderson, Jan Hubicka, Andrew Pinski On Jan 20, 2004, at 06:25, Jan Hubicka wrote: > Actually the casts don't have to be very complex. See for instance: > <D175450>_4 = (short unsigned int * const *)&__first; > T.14797_7 = *<D175450>_4; > <D175454>_9 = (short unsigned int * const *)&__last; > T.14799_12 = *<D175454>_9; > these two are operands of template: > > void std::fill(_ForwardIter, _ForwardIter, const _Tp&) [with > _ForwardIter = __gnu_cxx::__normal_iterator<short unsigned int*, > std::vector<short unsigned int, std::allocator<short unsigned int> > > >, _Tp = short unsigned int] (__first, __last, __value) > > so if I read it right, they shall differ only in constantness. There is also PR 8781 which has the same exact problem and it is shorter. Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: tree-SSA and indirect references. 2004-01-20 16:57 ` Andrew Pinski @ 2004-01-20 18:15 ` Richard Henderson 0 siblings, 0 replies; 7+ messages in thread From: Richard Henderson @ 2004-01-20 18:15 UTC (permalink / raw) To: Andrew Pinski; +Cc: Jan Hubicka, Jason Merrill, law, gcc, Jan Hubicka On Tue, Jan 20, 2004 at 08:57:24AM -0800, Andrew Pinski wrote: > There is also PR 8781 which has the same exact problem and it is > shorter. This is a different problem. There are no casts involved. After SRA and DCE, we have pred<D1926> = f; pred<D1933>.pred = &pred<D1926>; pred<D1940>.pred = &pred<D1933>; pred<D1947>.pred = &pred<D1940>; pred<D1954>.pred = &pred<D1947>; pred<D1961>.pred = &pred<D1954>; pred<D1968>.pred = &pred<D1961>; pred<D1975>.pred = &pred<D1968>; pred<D1982>.pred = &pred<D1975>; T.1<D2040>_54 = pred<D1933>.pred; T.2<D2041>_55 = *T.1<D2040>_54; T.3<D2042>_56 = T.2_55 (); We don't get f propagated to T.2<D2041>_55 because (1) SRA doesn't work on structures whose address is taken, and (2) we don't have even *simplistic* propagation of field values for addressed structs. Point the second is criminal. The reason we don't delete pred<D1940>.pred = &pred<D1933>; pred<D1947>.pred = &pred<D1940>; pred<D1954>.pred = &pred<D1947>; pred<D1961>.pred = &pred<D1954>; pred<D1968>.pred = &pred<D1961>; pred<D1975>.pred = &pred<D1968>; pred<D1982>.pred = &pred<D1975>; is that we think that these objects have all have their address taken, and thus might be referenced by the function call. There was one more iteration on the end that DCE removed, so in theory repeated applications of DCE would clean this up. However, I think the most dramatic improvement would be escape analysis. None of the addresses in the chain is stored in globally accessible memory, and thus the function call can't reference any of the addresses, and thus they are all dead. r~ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-01-20 18:15 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-01-20 0:31 tree-SSA and indirect references Jan Hubicka 2004-01-20 0:59 ` Richard Henderson 2004-01-20 9:50 ` Jan Hubicka 2004-01-20 10:21 ` Richard Henderson 2004-01-20 14:25 ` Jan Hubicka 2004-01-20 16:57 ` Andrew Pinski 2004-01-20 18:15 ` Richard Henderson
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).