Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Jonas Maebe via fpc-devel wrote:

On 14/12/2023 08:41, Adriaan van Os via fpc-devel wrote:

Jonas Maebe via fpc-devel wrote:

I'd rather not introduce directives that are specific to clang, and 
especially none only apply to the next loop. We don't have a single 
directive yet that works like this.


The latter is a good point and that's why I would suggest to make 
their Pascal equivalents valid, not for the next for-loop, but 
until-otherwise. Then, a loop can be explicitely targeted with {$push 
...} and {$pop}.


I don't think that makes much sense. Most of the time, the loops in a 
single source file will be quite different and need different explicit 
unroll instructions, if any. There is a reason why they only apply to 
the next loop in clang.


It's just that directives don't work very well in that context, and 
hence my initial suggestion to use attributes instead. I'm by no means 
married to that proposal, but I don't think directives are a good 
approach either.


GNU Pascal has attributes . They 
are fine for me.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Jonas Maebe via fpc-devel]

On 14/12/2023 08:41, Adriaan van Os via fpc-devel wrote:

Jonas Maebe via fpc-devel wrote:

I'd rather not introduce directives that are specific to clang, and 
especially none only apply to the next loop. We don't have a single 
directive yet that works like this.


The latter is a good point and that's why I would suggest to make their 
Pascal equivalents valid, not for the next for-loop, but 
until-otherwise. Then, a loop can be explicitely targeted with {$push 
...} and {$pop}.


I don't think that makes much sense. Most of the time, the loops in a 
single source file will be quite different and need different explicit 
unroll instructions, if any. There is a reason why they only apply to 
the next loop in clang.


It's just that directives don't work very well in that context, and 
hence my initial suggestion to use attributes instead. I'm by no means 
married to that proposal, but I don't think directives are a good 
approach either.



Jonas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Jonas Maebe via fpc-devel wrote:

I'd rather not introduce directives that are specific to clang, and 
especially none only apply to the next loop. We don't have a single 
directive yet that works like this.


The latter is a good point and that's why I would suggest to make their Pascal equivalents valid, 
not for the next for-loop, but until-otherwise. Then, a loop can be explicitely targeted with 
{$push ...} and {$pop}.


Regards,

Adriaan van Os
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Michael Van Canneyt via fpc-devel wrote:


Maybe a single {$PRAGMA XYZ} directive can be introduced to control this
kind of stuff, with a fixed list of XYZ. Backends can intepret the XYZ 
pragmas as they see fit.


Yes, a {$pragma} directive is fine for me. It seems absurd to ignore code improvement capabilities 
that we get for free with the llvm back-end.


Regards,

Adriaan van Os

{$pragma vectorize ON}
{$pragma vectorize OFF}
{$pragma vectorize WIDTH=n}
{$pragma vectorize TYPE=FIXED}
{$pragma vectorize TYPE=SCALABLE}
{$pragma vectorize PREDICATE=ON}
{$pragma vectorize PREDICATE=OFF}

For a description, see 
. And

{$pragma unroll ON}
{$pragma unroll OFF}
{$pragma unroll FULL}
{$pragma unroll COUNT=n}

For a description, see 
. And
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Michael Van Canneyt via fpc-devel]

On Wed, 13 Dec 2023, Jonas Maebe via fpc-devel wrote:


On 09/12/2023 13:35, Adriaan van Os via fpc-devel wrote:

Jonas Maebe via fpc-devel wrote:
So if/when we would get FPC equivalents of such directives, I could 
translate those to LLVM IR as well.


Then I suggest the following (and I can prepare a patch to the code and 
docs if it were to be accepted)


$vectorize ON}
{$vectorize OFF}
{$vectorize WIDTH=VALUE}
{$vectorize TYPE=FIXED}
{$vectorize TYPE=SCALABLE}
{$vectorize PREDICATE=ON}
{$vectorize PREDICATE=OFF}

For a description, see 
. And


{$unroll ON}
{$unroll OFF}
{$unroll FULL}
{$unroll COUNT=VALUE}

For a description, see 


.

I'd rather not introduce directives that are specific to clang, and 
especially none only apply to the next loop. We don't have a single 
directive yet that works like this.


Maybe attributes would be more appropriate, although I don't think 
Delphi (or FPC) currently supports attributes for statements.


Please don't:
Attributes are designed for runtime consumption. I'm heavily opposed to
start using them to influence the code generation. The compiler should
remain ignorant of their meaning and use.

Maybe a single {$PRAGMA XYZ} directive can be introduced to control this
kind of stuff, with a fixed list of XYZ. 
Backends can intepret the XYZ pragmas as they see fit.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Jonas Maebe via fpc-devel]

On 09/12/2023 13:35, Adriaan van Os via fpc-devel wrote:

Jonas Maebe via fpc-devel wrote:
So if/when we would get FPC equivalents of such directives, I could 
translate those to LLVM IR as well.


Then I suggest the following (and I can prepare a patch to the code and 
docs if it were to be accepted)


$vectorize ON}
{$vectorize OFF}
{$vectorize WIDTH=VALUE}
{$vectorize TYPE=FIXED}
{$vectorize TYPE=SCALABLE}
{$vectorize PREDICATE=ON}
{$vectorize PREDICATE=OFF}

For a description, see 
. And


{$unroll ON}
{$unroll OFF}
{$unroll FULL}
{$unroll COUNT=VALUE}

For a description, see 
.


I'd rather not introduce directives that are specific to clang, and 
especially none only apply to the next loop. We don't have a single 
directive yet that works like this.


Maybe attributes would be more appropriate, although I don't think 
Delphi (or FPC) currently supports attributes for statements.



Also, I suggest

-Cl   Pass xxx to Clang as pragma on the command-line.


You can already pass command line options to clang using the generic -ao 
command line parameter.



Jonas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Jonas Maebe via fpc-devel wrote:

On 09/12/2023 10:07, Adriaan van Os via fpc-devel wrote:

Another question. Is there a way to put pragmas in fpc source code to 
be passed to CLang, eg. those mentioned here 
 ? That would gain a lot, at 
little cost.


No. However, FPC command line parameters (e.g. -O, -Cp) and 
directives/modifiers (e.g. inline, const, constref, ...) get translated 
into LLVM directives wherever possible.


So if/when we would get FPC equivalents of such directives, I could 
translate those to LLVM IR as well.


Then I suggest the following (and I can prepare a patch to the code and docs if 
it were to be accepted)

$vectorize ON}
{$vectorize OFF}
{$vectorize WIDTH=VALUE}
{$vectorize TYPE=FIXED}
{$vectorize TYPE=SCALABLE}
{$vectorize PREDICATE=ON}
{$vectorize PREDICATE=OFF}

For a description, see 
. And

{$unroll ON}
{$unroll OFF}
{$unroll FULL}
{$unroll COUNT=VALUE}

For a description, see 
.


LLVM equivalents of these compiler switches will be passed (by Jonas) to Clang 
as IR methadata.

Also, I suggest

-Cl   Pass xxx to Clang as pragma on the command-line.

Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Jonas Maebe via fpc-devel]

On 09/12/2023 10:07, Adriaan van Os via fpc-devel wrote:

Another question. Is there a way to put pragmas in fpc source code to be 
passed to CLang, eg. those mentioned here 
 ? That would gain a lot, at 
little cost.


No. However, FPC command line parameters (e.g. -O, -Cp) and 
directives/modifiers (e.g. inline, const, constref, ...) get translated 
into LLVM directives wherever possible.


So if/when we would get FPC equivalents of such directives, I could 
translate those to LLVM IR as well.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Jonas,

It's indeed easier, and it also supports some preprocessing that llc 
doesn't (I don't remember what exactly llc didn't support, perhaps 
comments). It's also faster since you call one tool rather than 2 or 3.


Another question. Is there a way to put pragmas in fpc source code to be passed to CLang, eg. those 
mentioned here  ? That would gain a lot, at little cost.


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Jonas Maebe via fpc-devel]

On 08/12/2023 04:23, Adriaan van Os via fpc-devel wrote:

Jonas Maebe via fpc-devel wrote:
Because of this reason, FPC only uses llvm.dbg.addr. But clang still 
uses llvm.dbg.declare, and when I change FPC to use that one, the 
debug info for the variables in your test program is correct. So I'll 
change FPC to also use llvm.dbg.declare.


Done.


Just out of curiosity: Clang is by fpc used as a driver program, as it 
is asier to call it than tools like llc, opt and llvm-linker ?


It's indeed easier, and it also supports some preprocessing that llc 
doesn't (I don't remember what exactly llc didn't support, perhaps 
comments). It's also faster since you call one tool rather than 2 or 3.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Adriaan van Os via fpc-devel]

Jonas Maebe via fpc-devel wrote:
Because of this reason, FPC only uses llvm.dbg.addr. But clang still 
uses llvm.dbg.declare, and when I change FPC to use that one, the 
debug info for the variables in your test program is correct. So I'll 
change FPC to also use llvm.dbg.declare.


Done.


Just out of curiosity: Clang is by fpc used as a driver program, as it is asier to call it than 
tools like llc, opt and llvm-linker ?


Regards,

Adriaan van Os

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Jonas Maebe via fpc-devel]

On 06/12/2023 22:25, Jonas Maebe via fpc-devel wrote:

https://releases.llvm.org/11.0.0/docs/SourceLevelDebugging.html#format-common-intrinsics
 states that llvm.dbg.declare is identical to llvm.dbg.addr, except that it 
works badly in the context of optimisations, and that as a result it is 
deprecated and will be removed.

Because of this reason, FPC only uses llvm.dbg.addr. But clang still 
uses llvm.dbg.declare, and when I change FPC to use that one, the debug 
info for the variables in your test program is correct. So I'll change 
FPC to also use llvm.dbg.declare.


Done.


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Jonas Maebe via fpc-devel]

On 06/12/2023 22:17, Martin Frb via fpc-devel wrote:
If I have enough code, so clang does not optimize the entire function 
away in -O1, then clang writes info for some of the lines.

Actually the variable is in a (or several?) registers.
And clang misses some lines too.
But it covers some lines in the procedure.


https://releases.llvm.org/11.0.0/docs/SourceLevelDebugging.html#format-common-intrinsics 
states that llvm.dbg.declare is identical to llvm.dbg.addr, except that 
it works badly in the context of optimisations, and that as a result it 
is deprecated and will be removed.


Because of this reason, FPC only uses llvm.dbg.addr. But clang still 
uses llvm.dbg.declare, and when I change FPC to use that one, the debug 
info for the variables in your test program is correct. So I'll change 
FPC to also use llvm.dbg.declare.



Jonas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Martin Frb via fpc-devel]

On 06/12/2023 21:58, Martin Frb via fpc-devel wrote:

On 06/12/2023 21:05, Jonas Maebe via fpc-devel wrote:

On 06/12/2023 17:37, Martin Frb via fpc-devel wrote:

Not suer if the issue is within Fpc or clang...

Should this be reported against Fpc?


FPC defines the variables' debug info at the start of the function 
and defines their lifetime as starting at the beginning of the 
function and continuing until the end. But LLVM is free to modify 
these if it notices these are too pessimistic


My guess is that even without optimisations, LLVM notices these 
variables' values are not really used later on and reduces the 
variables' live range.


Strange, then clang has a serious issue.


But, yes it probably is clang.

If I have enough code, so clang does not optimize the entire function 
away in -O1, then clang writes info for some of the lines.

Actually the variable is in a (or several?) registers.
And clang misses some lines too.
But it covers some lines in the procedure.


With -O- it never is in a register...
Well it gets loaded sometimes, but it' always also on the stack.
Seems like clang doesn't see it while it is on the stack.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Martin Frb via fpc-devel]

On 06/12/2023 21:05, Jonas Maebe via fpc-devel wrote:

On 06/12/2023 17:37, Martin Frb via fpc-devel wrote:

Not suer if the issue is within Fpc or clang...

Should this be reported against Fpc?


FPC defines the variables' debug info at the start of the function and 
defines their lifetime as starting at the beginning of the function 
and continuing until the end. But LLVM is free to modify these if it 
notices these are too pessimistic


My guess is that even without optimisations, LLVM notices these 
variables' values are not really used later on and reduces the 
variables' live range.


Strange, then clang has a serious issue.

I changed the code, so they are used. Still clang only defines the 
location list for the "end" keyword.

(I also removed the nested aspect)

Which in this case is
/home/m/laz/projects/clang1/clang_nested_proc_1.lpr:17  end;
0040143A 4883C448 add rsp,$48
0040143E C3   ret

And the location list covers those 2 statements.

Maybe it's the version of clang (if anyone has a newer one setup...)

Is there a way to see what fpc tells clang? (in human readable form)


program clang_nested_proc_1;
{$mode objfpc}

  procedure Bar(a, b: integer);
  var
    c,d: integer;
  begin
    c:=Random(99);
    d:=Random(99);
    writeln(a,b,c,d);
    d:=d+a;
    c:=c+b;
    writeln(a,b,c,d);
  end;

procedure Foo;
begin
  Bar(1,2);
end;

begin
  Foo;
end.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong debug info when using clang backend

[Jonas Maebe via fpc-devel]

On 06/12/2023 17:37, Martin Frb via fpc-devel wrote:

Not suer if the issue is within Fpc or clang...

Should this be reported against Fpc?


FPC defines the variables' debug info at the start of the function and 
defines their lifetime as starting at the beginning of the function and 
continuing until the end. But LLVM is free to modify these if it notices 
these are too pessimistic


My guess is that even without optimisations, LLVM notices these 
variables' values are not really used later on and reduces the 
variables' live range.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel