!DEC$ ATTRIBUTES NOINLINE

[jimdempseyatthecove]

I have a program containing:

!DEC$ ATTRIBUTES NOINLINE :: CROSS
CALL CROSS (UDRGI,TUI, FDRGI)

[fortran]Recently I added a module to declare a generic interface for CROSS





interface CROSS SUBROUTINE CROSS_r_r_r(VA,VB,VC) use MOD_AVX real :: VA(3), VB(3), VC(3) END SUBROUTINE CROSS_r_r_r #ifdef _Use_AVX SUBROUTINE CROSS_ymm_ymm_ymm(VA,VB,VC) use MOD_AVX type(TypeYMM) :: VA(3), VB(3), VC(3) END SUBROUTINE CROSS_ymm_ymm_ymm SUBROUTINE CROSS_xmm_xmm_xmm(VA,VB, VC) use MOD_AVX type(TypeXMM) :: VA(3), VB(3), VC(3) END SUBROUTINE CROSS_xmm_xmm_xmm #endif end interface CROSS[/fortran]

The compiler (in Debug build) then complained about the attributes not matching.
By removing the !DEC$ ATTRIBUTES NOINLINE :: CROSS
the program would compile without complaint.

Jim Dempsey

[jimdempseyatthecove]

!@#$% wordpress

[Steven_L_Intel1]

Jim, would you please attach, as a file, a source that shows the error? I am not sure what you did.

[jimdempseyatthecove]

Too much time spent of vacation - eh?

[fortran]module MOD_foo interface CROSS SUBROUTINE CROSS_r_r_r(VA,VB,VC) real :: VA(3), VB(3), VC(3) END SUBROUTINE CROSS_r_r_r end interface CROSS end module MOD_foo program foo use MOD_foo real :: UDRGI(3), TUI(3), FDRGI(3) !DEC$ ATTRIBUTES NOINLINE :: CROSS CALL CROSS (UDRGI,TUI, FDRGI) end program foo [/fortran]

The problem is, in places, I selectively wish to NOT inline the call.
(iow, in other places I do wish to inline the call)

Forcing the INLINE attribute to be the same in the module as in the source code USE-ing the module is a bit strict.

Jim Dempsey

[Steven_L_Intel1]

Is there such a thing as too much vacation?

Now I see what you're getting at. The problem appears to be that the NOINLINE attribute is a property of the procedure, not of the call. The documentation says "You should place the directive option in the procedure whose inlining you want to influence." Given that, I'd wonder what it means to put the attribute outside the procedure. I don't think that there is the sort of control you are looking for.

I'll ask the developers for their thoughts on this.

[jimdempseyatthecove]

IMHO the INLINE / NOINLINE / FORCEINLINE

should be not only an attribute in defining/interfacing a procedure
but also a compiler directive at the place of call

It is not an unusual circumstance to want to have the control of where in the code inlining is performed or inhibited (as opposed to stuck with all or none).

Here is a hypothetical case.

Part of an application has a heavily used loop with a high density of calls to a subroutine. Assume that inlining the subroutine in this loop causes the L1 Instruction Cache to overflow. In this case you want inlining off.

A different part of the application has a smaller loop that iterates many times and has a low density of calls to the same subroutine. In this place you want inlining on.

How can you accomplish this if the INLINE attribute binds (only)with the definition/interface of the subroutine as opposed to place of call?

Jim Dempsey

[Steven_L_Intel1]

I agree with you, and note that Intel C++ treats its corresponding #pragma inline the way you want. I have asked the developers about this.