This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for G95 alias processing
- From: Paul Brook <paul at codesourcery dot com>
- To: Zhao kejia <kejia_zh at nudt dot edu dot cn>, fortran at gcc dot gnu dot org,gcc-patches at gcc dot gnu dot org
- Date: Sun, 15 Feb 2004 21:04:11 +0000
- Subject: Re: Patch for G95 alias processing
- Organization: CodeSourcery
- References: <20040213081615.46D3B5B2CA@ds20.nudt.edu.cn>
On Friday 13 February 2004 8:16 am, Zhao kejia wrote:
> Hi, Paul,
>
> This is a patch for Fortran-special alias processing.
> This patch can improves performance of G95.
<snip>
> The major function is gfc_get_alias_set(), it simply
> gives different alias set to each of program variables
> and variables generated by the compiler, except
> program variables with type of pointer(equivalence
> variables is not present because them have been
> resolved). The others modification in other functions
> is needed to enable the alias processing to work.
I'd like a comment similar to this in the code, describing what aliasing rules
are applied, and how this is implemented.
It isn't clear to me if/how variables with the TARGET attribute are handled.
> There are two reasons for these modifications, which
> is explained below:
>
> 1. There are a potential bug in gcc back-end if gcc
> would have distinguished the alias for each different
> variables. This bug may not emerge out because gcc
> gives the same alias set to all variables which has
> the same type, but it appears when we add Fortran-
> special alias processing. The code in the files
> ¡°lap.f90¡±, ¡°lap.f90.06.cse¡±, and
> ¡°lap.f90.07.addressof¡± show the bug. This bug causes
> the alias set of two memory references to a variable
> which had the same alias set originally in
> lap.f90.06.cse become different. The modification in
> put_reg_into_stack() in file function.c is to fix this
> bug.
It's probably best if you submit the changes to generic parts of the compiler
as a seperate patch. They will need approving seperately.
You have also made some static objects global. The declarations for these
should be moved into the appropriate header files. You should never have
extern decls in .c files.
> 2. Gcc simple tree optimization generates different
> base name for a array variable, such as both of T.7
> and T.8 for array P, as shown in files ¡°temp0-1.f90¡±
> and ¡°temp0-1.f90.t32.optimized¡±. This will cause a
> array have different alias set. To avoid this problem,
> we build a base name for each AS_EXPLICIT array. The
> related modification deals with other files except
> function.c.
I don't understand this fully, but I'm not sure that this is the correct
solution. I suspect there are other cases where the gimplifier/optimizers may
create temporary variables.
> I hope you can check this patch to see if there is any
> explicit problem that I don¡¯t see, because it would
> cause bugs which may be very difficuty to find if
> there are some problems, although it have passed check-
> f95, all benchmark programs in spec2000 CFP that G95
> can run, and all real application program we have.
Paul