[Bug c/89774] Add flag to force single precision

2019-03-20 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774

--- Comment #7 from Marius Messerschmidt  ---
Looks good, which options did you use?

[Bug c/89774] Add flag to force single precision

2019-03-20 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774

--- Comment #5 from Marius Messerschmidt  ---
I did checkt the output without --fsingle-precision-constant

Is this only enabled via -fsingle-precision-constant or at any optimization
level?

[Bug c/89774] Add flag to force single precision

2019-03-20 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774

Marius Messerschmidt  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |---

--- Comment #3 from Marius Messerschmidt  ---
Reopening issue

[Bug c/89774] Add flag to force single precision

2019-03-20 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774

Marius Messerschmidt  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

--- Comment #2 from Marius Messerschmidt  ---
This will cause issues the other way around as well.

I think that I did not state clearly what I meant...

Right now you can only use 'all double' or 'all float'. What I am looking for
is some kind of performance-oriented solution that will pick the 'best' option
for each literal.

Quick example:

void f() {
  float a = 2.0; // 2.0 -> single
  float b = 2.0 * b; // 2.0 -> single

  double d = 3.0;// 3.0 -> double
  double e = 3.0 * d;// 3.0 -> double

  double z = 2.0 * a + 3.0 * d; // both 2.0 and 3.0 -> double (only cast a)
}

The basic idea is to increase performance by reducing casting instructions.

Is something like that already implemented or if not, do you think that this is
useful and could be implemented?

[Bug c/89774] New: Add flag to force single precision

2019-03-20 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774

Bug ID: 89774
   Summary: Add flag to force single precision
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marius.messerschmidt at googlemail dot com
  Target Milestone: ---

It would be helpful if there was a flag (e.g. -fsingle-precision-literals) that
would cause gcc to treat floating point literals (e.g. 0.5 or 0.25 ...) in the
source code as single precision (float) and not double precision (double).

This could help improve performance of single precision code as right now there
are many conversion instructions (see objdump) which use quite a lot of runtime
(see perf).

[Bug tree-optimization/88763] Better Output for Loop Unswitching

2019-01-10 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763

--- Comment #12 from Marius Messerschmidt  ---
I think this messages look really good!
I believe that this contains everything required to actually work on improving
automatic unswitching, thank you very much!

Do you think that there is a chance that this will be included in GCC9?

[Bug tree-optimization/88763] Better Output for Loop Unswitching

2019-01-09 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763

--- Comment #9 from Marius Messerschmidt  ---
Created attachment 45397
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45397&action=edit
Basic testcase

As there where some more issues in the example I provided, I added it as an
attachment. Now it should work just fine.

[Bug tree-optimization/88763] Better Output for Loop Unswitching

2019-01-09 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763

--- Comment #8 from Marius Messerschmidt  ---
Oh minor error from my side, the "BAD LINE" should of course be above the
if/return block otherwise it would work just fine.

[Bug tree-optimization/88763] Better Output for Loop Unswitching

2019-01-09 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763

--- Comment #7 from Marius Messerschmidt  ---
Thanks a lot for working on this!

A simple example would be the following:


-- CODE ---

int calc(int x, int y, int *flag)
{
if(flag > 5)
return x + y;
else
return x * y;

*flag += 2; // BAD LINE
}

int main(int argc, char **argv)
{
int flag = argc;
int array[250*250];
for(int i = 0; i < 250; i++)
{
for(int j = 0; j < 250
array[i*250 + j] = calc(i, j, &flag);
}

return array[42 + argc];
}

---

The line marked with "BAD LINE" is obviously preventing the unswitching as the
loop condition is no longer constant during the loop. If you uncomment the line
gcc reports ";; unswitched loop" which is great. But if you keep the line, you
get no output at all. The minimal output I would expect is:

";; not unswitching loop: REASON"

so in this case:

";; not unswitching loop: Condition is not invariant"

To further improve the output it would be great if there would be some more
information about the loop, but I do not know which information is available
during this stage. The most helpful additional information would be (also
applies for the successful message):

  - File
  - Function
  - Line number of the loop head (or some other way to identify the loop, e.g.
loop number XY)
  - Line number of the if-statement that should be unswitched out of the loop
  - Line number of the issue that caused the loop unswitching to stop so in the
example above the commented line.

So I think the perfect log message would be something like this:

";; unswitching loop: testFile.c:82 (Condition: otherFile.c:502)"
";; not unswitching loop: testFile.c:91: Condition (otherFile.c:541) is not
invariant (modified at otherFile.c:32)"


But as I said above I do not know how many information about the original
source file is still available during this stage.

[Bug tree-optimization/88763] Better Output for Loop Unswitching

2019-01-09 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763

--- Comment #3 from Marius Messerschmidt  ---
Sorry but I do not fully understand what you mean. Do you suggest using
different command line arguments?

So far I tried:

-fdump-tree-all
-fdump-tree-unswitch

and

-fopt-info-all-optall

But none of them told me the all the things that I would wish to know, most
important the reason why a particular loop was skipped during unswitching (e.g.
because it is not invariant or so (right now it already reports a few things
with -fdump-tree-unswitch like too-many-instructions or too-many-branches))

[Bug tree-optimization/88763] Better Output for Loop Unswitching

2019-01-09 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763

--- Comment #2 from Marius Messerschmidt  ---
Sorry but I do not fully understand what you mean. Do you suggest using
different command line arguments?

So far I tried:

-fdump-tree-all
-fdump-tree-unswitch

and

-fopt-info-all-optall

But none of them told me the all the things that I would wish to know, most
important the reason why a particular loop was skipped during unswitching (e.g.
because it is not invariant or so (right now it already reports a few things
with -fdump-tree-unswitch like too-many-instructions or too-many-branches))

[Bug tree-optimization/88763] New: Better Output for Loop Unswitching

2019-01-08 Thread marius.messerschmidt at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763

Bug ID: 88763
   Summary: Better Output for Loop Unswitching
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marius.messerschmidt at googlemail dot com
  Target Milestone: ---

I work on a project where we heavily rely on the loop-unswitching feature of
GCC (-funswitch-loops). I started working with the log generated by
-fdump-tree-unswitch.

I started noticing, that the output of the option is very limited. It does only
report a few cases where the optimizer could not unswitch a loop. But in the
source file (gcc/tree-ssa-loop-unswitch.c) there are quite a lot more checks
that lead to a not unswitched loop. Especially the "not invariant" case could
be realy helpfull in the logs.
I tried to implement further warnings, but I do not fully understand every case
in the file, so I am asking someone with better understanding of the internals
of GCC to either fix the bug or explain a few things for me.

Many thanks in Advance :)