From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: Mark Mitchell Cc: jbuck@synopsys.com, gcc@gcc.gnu.org, rms@gnu.org Subject: Re: type based aliasing again Date: Thu, 09 Sep 1999 02:20:00 -0000 Message-id: <3172.936868662@upchuck.cygnus.com> References: <19990908202957F.mitchell@codesourcery.com> X-SW-Source: 1999-09/msg00349.html In message < 19990908202957F.mitchell@codesourcery.com >you write: > I agree that C is reasonable. But, it is not technically viable at > compile-time; the violation of the rule is a dynamic property. For > example, consider: > > if (0) { > /* Do illegal aliasing stuff. */ > } > > If we do dead-code elimination late, we might ask questions about the > aliasing in the conditional code. Since that code never executes, > ANSI says there's no violation. Warning here is sensible, though, > just as warning on `*((int*) 0) = 3' in the conditional code would be > sensible. FYI, this kind of code could be deleted at a variety of stages in compilation depending on what optimization exposed the unreachable code (terminology note, this is unreachable code, not dead code ;-) For example, "if (0)" at the source level would probably be zapped by the first jump pass. I do not believe we do any aliasing checks before jump1. cse can expose code like this, and we do aliasing queries in cse. When CSE exposes this code it is eliminated immediately after cse by a jump pass. gcse can also expose code like this. The current snapshots do not have any aliasing tied into gcse. However, basic global load motion is done and will be donated as soon as I can find some time. At that point gcse will be doing alias queries. Also note global store motion is also in the pipeline. If gcse exposes any code like this it will be deleted by a jump pass after gcse. etc etc etc. > A technical problem is giving an intelligent warning; we no longer > know the types of the variables involved, by the time we could warn. > We are in RTL-land at that point. But, even Right, no types. Getting line numbers may not be particularly easy either depending on the pass. The current way I've handling aliasing issues in gcse would make it straight forward to get the line number for the two memory references. [ Remember, we're comparing two values, which could come from different lines. ] jeff From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: Mark Mitchell Cc: jbuck@synopsys.com, gcc@gcc.gnu.org, rms@gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <3172.936868662@upchuck.cygnus.com> References: <19990908202957F.mitchell@codesourcery.com> X-SW-Source: 1999-09n/msg00349.html Message-ID: <19990930180200.MbBHTXJa984W8jGzeG4uKnkB4td4dxeRTF5m0awCmpY@z> In message < 19990908202957F.mitchell@codesourcery.com >you write: > I agree that C is reasonable. But, it is not technically viable at > compile-time; the violation of the rule is a dynamic property. For > example, consider: > > if (0) { > /* Do illegal aliasing stuff. */ > } > > If we do dead-code elimination late, we might ask questions about the > aliasing in the conditional code. Since that code never executes, > ANSI says there's no violation. Warning here is sensible, though, > just as warning on `*((int*) 0) = 3' in the conditional code would be > sensible. FYI, this kind of code could be deleted at a variety of stages in compilation depending on what optimization exposed the unreachable code (terminology note, this is unreachable code, not dead code ;-) For example, "if (0)" at the source level would probably be zapped by the first jump pass. I do not believe we do any aliasing checks before jump1. cse can expose code like this, and we do aliasing queries in cse. When CSE exposes this code it is eliminated immediately after cse by a jump pass. gcse can also expose code like this. The current snapshots do not have any aliasing tied into gcse. However, basic global load motion is done and will be donated as soon as I can find some time. At that point gcse will be doing alias queries. Also note global store motion is also in the pipeline. If gcse exposes any code like this it will be deleted by a jump pass after gcse. etc etc etc. > A technical problem is giving an intelligent warning; we no longer > know the types of the variables involved, by the time we could warn. > We are in RTL-land at that point. But, even Right, no types. Getting line numbers may not be particularly easy either depending on the pass. The current way I've handling aliasing issues in gcse would make it straight forward to get the line number for the two memory references. [ Remember, we're comparing two values, which could come from different lines. ] jeff