🚀 go-pugleaf

In article <5224@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> What I don't do is suggest that the compiler involve itself in an
> elaborate scheme to avoid requiring the user to make a few simple
> declarations about aliasing.  Even if your scheme works (it's long,
> I'll have to study it),

It works, and it's not long. You just haven't listened to my short
explanations. I await the end of your ``study,'' and your final
admission that a C compiler can, without any hints from the user, detect
the non-aliasing in Fortran-converted-to-C array code.

> it enlarges .o files by factors which are
> probably exponential in the number of procedure arguments;

Wrong. You said many months ago that most code does not show aliasing.
If this is true, then the compiler can generate two partitions (which
means double-size .o files) and use the more efficient one in all cases.
It only needs to generate more partitions if you actually *do* have
aliasing which you want the compiler to detect on a fine grain. (As
usual, *if* the compiler does interprocedural analysis, it can figure
out exactly which partitions are necessary.)

> it
> requires that many extra passes through the compiler for each
> code (at least through the code generation phase of the compiler);

I pointed this out in the article you're studying. Yes, Jim, if you
generate code that assumes aliasing and code that does not, you have
indeed generated twice as much code.

> and it looks extremely cumbersome and unreliable.

It is not cumbersome, it is easy to implement, and it is perfectly
reliable.

> And, it _does_
> require modifications to the loader (at least to the extent of
> recognising all the long suffixes to the procedure names which
> describe which combination of aliasing is allowed in each object
> code version).

You are grasping at straws. The number of the partition chosen takes at
most a few bits to encode.

---Dan