Re: [PATCH, v2] Fortran: ordering of hidden procedure arguments [PR107441]
Le 03/11/2022 à 23:03, Harald Anlauf a écrit : Am 03.11.22 um 11:06 schrieb Mikael Morin: Le 02/11/2022 à 22:19, Harald Anlauf via Fortran a écrit : I do see what needs to be done in gfc_get_function_type, which seems in fact very simple. But I get really lost in create_function_arglist when trying to get the typelist right. One thing is I really don't understand how the (hidden_)typelist is managed here. How does that macro TREE_CHAIN work? Can we somehow chain two typelists the same way we chain arguments? TREE_CHAIN is just a linked list "next" pointer like there is in the fortran frontend a "next" pointer in gfc_ref or gfc_actual_arglist structures. Yes, we can chain typelists; the implementation of chainon in tree.cc is just TREE_CHAIN appending under the hood. (Failing that, I tried to split the loop over the dummy arguments in create_function_arglist into two passes, one for the optional+value variant, and one for the rest. It turned out to be a bad idea...) Not necessarily a bad idea, but one has to be careful to keep linked lists synchronized with argument walking. The most simple, I think, is to move the hidden_typelist advancement for optional, value presence arguments from the main loop to a preliminary loop. I hope it helps. I've spent some time not only staring at create_function_arglist, but trying several variations handling the declared hidden parms, and applying the necessary adjustments to gfc_get_function_type. (Managing linked trees is not the issue, just understanding them.) I've been unable to get the declarations in sync, and would need help how to debug the mess I've created. Dropping my patch for the time being. If you want, we can meet on IRC somewhen (tonight?).
Re: adding attributes
On Thu, 3 Nov 2022 00:19:26 +0100
Bernhard Reutner-Fischer wrote:
> So target_clones is one thing. What other attributes would be important?
> > doing something previously! (I don't know if I'll actually be able to
> > work on it in the end, at least on work time.)
>
> heh, me neither. Luckily yesterday was a holiday, so what i ended up
> with was the following, fya.
> Consider:
$ cat gcc/testsuite/gfortran.dg/attr_target_clones-1.F90; echo EOF
! { dg-require-ifunc "" }
! { dg-options "-O1" }
! { dg-additional-options "-fdump-tree-optimized" }
! It seems arch defines are not defined?!
! See fortran.cpp FIXME: Pandora's Box
! Ok, so enterprise-level bugfix:
! { dg-additional-options "-D__i386__=1" { target { i?86-*-* x86_64-*-* } } }
! { dg-additional-options "-D__powerpc__=1" { target { powerpc*-*-* } } }
! { dg-skip-if "test not yet implemented for target" { ! {i?86-*-* x86_64-*-*
powerpc*-*-*} } }
!! { dg- skip-if "needs optimize" { *-*-* } { "*" } { " -O0 " } }
! Test __attribute__ ((target_clones ("foo", "bar")))
!
module m
implicit none
contains
subroutine sub1()
#if defined __i386__ || defined __x86_64__
!GCC$ ATTRIBUTES target_clones("avx", "sse","default") :: sub1
#elif defined __powerpc__
!GCC$ ATTRIBUTES target_clones("power10", "power9","default") :: sub1
#endif
print *, 4321
end
end module m
! { dg-final { scan-tree-dump-times {(?n)void \* __m_MOD_sub1\.resolver \(\)} 1
"optimized" } }
! { dg-final { scan-tree-dump-times {(?n)void __m_MOD_sub1\.(?:avx|power10)
\(\)} 1 "optimized" } }
! { dg-final { scan-tree-dump-times {(?n)void __m_MOD_sub1\.(?:sse|power9)
\(\)} 1 "optimized" } }
! { dg-final { scan-tree-dump-times {(?n)void sub1 \(\)} 1 "optimized" } }
!! and a non-assembly hint on the ifunc
! { dg-final { scan-tree-dump-times {Function sub1 \(__m_MOD_sub1\.default,} 1
"optimized" } }
EOF
2 patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605081.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604981.html
(the testcase mentioned in the latter is superseded be the blurb above)
One would have to cleanup the parser (see "XXX: Rephrase this in a
sane, understandable manner..") and add some more testcases, for several
malformed attribute strings. Maybe i'll get to it during the weekend or
some evening.
Not sure about the usefulness though.
And not sure if fellow gfortraners would accept this attribute
target_clones in there in the first place..
cheers,
