Re: Artificial front-end variables?

[Steven Bosscher <stevenb at suse dot de>]

On Saturday 05 June 2004 18:48, Tobias Schlüter wrote:
> I've been looking at PR12366, which looks something like this:
>     b = a( (/ 1, 2, 3, 4 /) )
> where b and a are arrays. The problem seemingly is that the code
> generators expect a variable for a vector subscript. It seemed to me
> that the easiest cure would be to introduce an artificial variable, and
> change the code to
>     t = (/ 1, 2, 3, 4 /)
>     b = a(t)
> with t the artificial variable, of course. I verified that this compiles
> correctly when generated manually.
>
> I thought about adding this feature to the compiler, it seems easy
> enough. All that is necessary appears to be
> 1) a new attribute "artificial" for gfc_symbol's & functions to generate
> them with unique names
> 2) a modification to trans-decl which marks declarations as artificial,
> if attr.artificial is set
>
> I was wondering if you think that something like this would be useful.
>
> Other applications that I can think of are in the scalarizer (I don't
> understand at all how our scalarizer works, but I'm wondering if it
> couldn't be modified to create gfc_code structures once artificial
> symbols were available), and nested array operations like c =
> matmul(a,matmul(a,b)) -> t = matmul(a,b); c = matmul(a,t) which should
> cure our issues with being "unable to find scalarization loop", and
> maybe others.
>
> Thoughts?

I have wanted such a feature for a long time, it would be useful in
many places (I first needed it when we wanted to generate code for
SELECT CASE, three years ago).  We then decided to do it in a different
way so it was never implemented.  If you you can do this, go ahead, it
would be very useful.

Gr.
Steven