Recent

Author Topic: Call to subroutine, marked as inline is not inline  (Read 861 times)

andersonscinfo

  • Full Member
  • ***
  • Posts: 141
Call to subroutine, marked as inline is not inline
« on: June 13, 2024, 04:59:46 pm »
Hi, I have code using variables of the variant type, and it keeps giving an annoying message from the compiler, in fact this should be something that I should pay more attention to, I would like to know if I am doing the right thing by ignoring it, or if I should change this code to make it more explicit, and so these messages stop appearing.
Code: Pascal  [Select][+][-]
  1. function TConfigLocal.Get(const APath: String; const APadrao: Variant
  2.   ): IJSONValue;
  3. Var
  4.   VStr: TArrayOfString;
  5. begin
  6.   VStr:=APath.Split('.');
  7.   Result:=TJSONString.New(
  8.     Get(VStr[0], VStr[1], APadrao)
  9.   );
  10. end;
the image is attached

MarkMLl

  • Hero Member
  • *****
  • Posts: 7118
Re: Call to subroutine, marked as inline is not inline
« Reply #1 on: June 13, 2024, 05:14:23 pm »
Ignore it, or tell the IDE to ignore it.

In most cases that means that the abstract structure (tree) that the compiler uses to represent a function exceeds the hardcoded limit (number of nodes) that the FPC developers think is appropriate: my recollection is that this is around 40 and you can get there either by having too many lines, excessively complex expressions, or lots of fancy address etc. handling.

Frankly, and this is my personal (hence uninformed :-) position, is that the inline keyword should be obeyed unconditionally since from the POV of the language it appears in the same context as a memory model or forward directive: if the compiler really can't honour it then that should be an error rather than a warning. However I'm not a core developer, and I'm sure that if I were they'd browbeat me until I conformed to the majority opinion :-)

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 15202
  • Censorship about opinions does not belong here.
Re: Call to subroutine, marked as inline is not inline
« Reply #2 on: June 13, 2024, 05:21:45 pm »
Yes, indeed, and it is a note, not a warning.
Especially using variants, the code becomes too complex to inline.
Are you sure you need a variant here?
Because that will slow down your code anyway!, inlined or not.
Variants are guaranteed to provide slow code.
For - much - faster code, just provide overloaded functions for the types you really need and those will usually be inlined.
« Last Edit: June 13, 2024, 05:26:07 pm by Thaddy »
Of course the national anthem of the U.S.A. was written by Jimi Hendrix, didn't you know that?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11655
  • FPC developer.
Re: Call to subroutine, marked as inline is not inline
« Reply #3 on: June 13, 2024, 05:26:13 pm »
Both Split and .new() probably allocate memory, so than it is already beyond the magnitude where inline is useful. Also there is a implicit try finally because of the managed types.

For inline to have a decent effect, the function overhead (parameter preparation, actual call, prologue and epilogue) need to be relatively large to what the function does, and this function doesn't look like it.

Thaddy

  • Hero Member
  • *****
  • Posts: 15202
  • Censorship about opinions does not belong here.
Re: Call to subroutine, marked as inline is not inline
« Reply #4 on: June 13, 2024, 05:35:33 pm »
I just tested: when I change variant to string it is inlined....
Of course the national anthem of the U.S.A. was written by Jimi Hendrix, didn't you know that?

andersonscinfo

  • Full Member
  • ***
  • Posts: 141
Re: Call to subroutine, marked as inline is not inline
« Reply #5 on: June 13, 2024, 06:54:04 pm »
Thank you everyone, at the end I will make some adjustments and remove the variant for an "IJsonValue" type, again thank you very much...

Att.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11655
  • FPC developer.
Re: Call to subroutine, marked as inline is not inline
« Reply #6 on: June 13, 2024, 07:13:50 pm »
I just tested: when I change variant to string it is inlined....

If it allows it, doesn't mean it is sane. It is just an upper limit.

Thaddy

  • Hero Member
  • *****
  • Posts: 15202
  • Censorship about opinions does not belong here.
Re: Call to subroutine, marked as inline is not inline
« Reply #7 on: June 13, 2024, 08:34:17 pm »
No, Marco, it is the variant that prevents ilining it.
Of course the national anthem of the U.S.A. was written by Jimi Hendrix, didn't you know that?

PascalDragon

  • Hero Member
  • *****
  • Posts: 5586
  • Compiler Developer
Re: Call to subroutine, marked as inline is not inline
« Reply #8 on: June 13, 2024, 09:49:38 pm »
No, Marco, it is the variant that prevents ilining it.

Yes, it prevents it, but marcov was talking about whether inline made sense there.

Hi, I have code using variables of the variant type, and it keeps giving an annoying message from the compiler, in fact this should be something that I should pay more attention to, I would like to know if I am doing the right thing by ignoring it, or if I should change this code to make it more explicit, and so these messages stop appearing.

You can ignore these notes, cause aside from not using variants you can't do anything against the hint, because it's triggered by the assignment itself.

In FPC main these kind of assignment operators can be successfully inlined, because FPC main is able to do cross-unit access for implementation-variables for inlining, in this case the VariantManager variable inside the System unit.

 

TinyPortal © 2005-2018