Re: Complex numbers support: discussions summary

[Richard Biener via Gcc]

On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc  wrote:
>
> Hi,
>
> We had very interesting discussions during our presentation with Paul on
> the
> support of complex numbers in gcc at the Cauldron.
>
> Thank you all for your participation !
>
> Here is a small summary from our viewpoint:
>
> - Replace CONCAT with a backend defined internal representation in RTL
> --> No particular problems
>
> - Allow backend to write patterns for operation on complex modes
> --> No particular problems
>
> - Conditional lowering depending on whether a pattern exists or not
> --> Concerns when the vectorization of split complex operations performs
> better
> than not vectorized unified complex operations
>
> - Centralize complex lowering in cplxlower
> --> No particular problems if it doesn't prevent IEEE compliance and
> optimizations (like const folding)
>
> - Vectorization of complex operations
> --> 2 representations (interleaved and separated real/imag): cannot
> impose one
> if some machines prefer the other
> --> Complex are composite modes, the vectorizer assumes that the inner
> mode is
> scalar to do some optimizations (which ones ?)
> --> Mixed split/unified complex operations cannot be vectorized easely
> --> Assuming that the inner representation of complex vectors is let to
> target
> backends, the vectorizer doesn't know it, which prevent some
> optimizations
> (which ones ?)
>
> - Explicit vectors of complex
> --> Cplxlower cannot lower it, and moving veclower before cplxlower is a
> bad
> idea as it prevents some optimizations
> --> Teaching cplxlower how to deal with vectors of complex seems to be a
> reasonable alternative
> --> Concerns about ABI or indexing if the internal representation is let
> to the
> backend and differs from the representation in memory
>
> - Impact of the current SLP pattern matching of complex operations
> --> Only with -ffast-math
> --> It can match user defined operations (not C99) that can be
> simplified with a
> complex instruction
> --> Dedicated opcode and real vector type choosen VS standard opcode and
> complex
> mode in our implementation
> --> Need to preserve SLP pattern matching as too many applications
> redefines
> complex and bypass C99 standard.
> --> So need to harmonize with our implementation
>
> - Support of the pure imaginary type (_Imaginary)
> --> Still not supported by gcc (and llvm), neither in our implementation
> --> Issues comes from the fact that an imaginary is not a complex with
> real part
> set to 0
> --> The same issue with complex multiplication by a real (which is split
> in the
> frontend, and our implementation hasn't changed it yet)
> --> Idea: Add an attribute to the Tree complex type which specify pure
> real / pure
> imaginary / full complex ?
>
> - Fast pattern for IEEE compliant emulated operations
> --> Not enough time to discuss about it
>
> Don't hesitate to add something or bring more precision if you want.
>
> As I said at the end of the presentation, we have written a paper which
> explains
> our implementation in details. You can find it on the wiki page of the
> Cauldron
> (https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf).

Thanks for the detailed presentation at the Cauldron.

My personal summary is that I'm less convinced delaying lowering is
the way to go.
I do think that if targets implement complex optabs we should use them but
eventually re-discovering complex operations from lowered form is going to be
more useful.  That's because as you said, use of _Complex is limited and people
inventing their own representation.  SLP vectorization can discover some ops
already with the limiting factor being that we don't specifically search for
only complex operations (plus we expose the result as vector operations,
requiring target support for the vector ops rather than [SD]Cmode operations).

There's the gimple-isel.cc or the widen-mul pass that perform
instruction selection
which could be enhanced to discover scalar [SD]Cmode operations.

Richard.

> Sylvain
>
>
>
>
>

Report from the additional type errors for GCC 14 BoF at Cauldron

[Florian Weimer via Gcc]

My understanding of the consensus goes as follows:

* We want to make some changes in this area for GCC 14.
* We should do the same thing that Clang does: default to the relevant
  -Werror= options.
* Unlike regular warnings, these warnings-as-errors should also apply
  to system headers.
* At least implict-int and implicit-function-declaration should be
  upgraded to errors in this way.
* It's too early to make the () changes and bool-as-keyword from C2X
  for GCC 14.
* We should fix the missing scope of the int-conversion warnings
  (PR109827).  Likweise for incompatible-pointer-types (PR109826).

Is this summary accurate?

I think the open issues are:

* Do we want to implement something else beside implicit-int and
  implicit-function-declaration?  (Candidates are int-conversion and
  incompatible-pointer-types, and the void vs non-void part of
  return-type, maybe others as previously discussed on the list.)
* How do we divide up the test suite cleanup work?

Thanks,
Florian

RE: Complex numbers support: discussions summary

[Tamar Christina via Gcc]

Hi,

I tried to find you two on Sunday but couldn't locate you. Thanks for the 
presentation!

> >
> > We had very interesting discussions during our presentation with Paul
> > on the support of complex numbers in gcc at the Cauldron.
> >
> > Thank you all for your participation !
> >
> > Here is a small summary from our viewpoint:
> >
> > - Replace CONCAT with a backend defined internal representation in RTL
> > --> No particular problems
> >
> > - Allow backend to write patterns for operation on complex modes
> > --> No particular problems
> >
> > - Conditional lowering depending on whether a pattern exists or not
> > --> Concerns when the vectorization of split complex operations
> > --> performs
> > better
> > than not vectorized unified complex operations
> >
> > - Centralize complex lowering in cplxlower
> > --> No particular problems if it doesn't prevent IEEE compliance and
> > optimizations (like const folding)
> >
> > - Vectorization of complex operations
> > --> 2 representations (interleaved and separated real/imag): cannot
> > impose one
> > if some machines prefer the other
> > --> Complex are composite modes, the vectorizer assumes that the inner
> > mode is
> > scalar to do some optimizations (which ones ?)
> > --> Mixed split/unified complex operations cannot be vectorized easely
> > --> Assuming that the inner representation of complex vectors is let
> > --> to
> > target
> > backends, the vectorizer doesn't know it, which prevent some
> > optimizations
> > (which ones ?)
> >
> > - Explicit vectors of complex
> > --> Cplxlower cannot lower it, and moving veclower before cplxlower is
> > --> a
> > bad
> > idea as it prevents some optimizations
> > --> Teaching cplxlower how to deal with vectors of complex seems to be
> > --> a
> > reasonable alternative
> > --> Concerns about ABI or indexing if the internal representation is
> > --> let
> > to the
> > backend and differs from the representation in memory
> >
> > - Impact of the current SLP pattern matching of complex operations
> > --> Only with -ffast-math
> > --> It can match user defined operations (not C99) that can be
> > simplified with a
> > complex instruction
> > --> Dedicated opcode and real vector type choosen VS standard opcode
> > --> and
> > complex
> > mode in our implementation
> > --> Need to preserve SLP pattern matching as too many applications
> > redefines
> > complex and bypass C99 standard.
> > --> So need to harmonize with our implementation
> >
> > - Support of the pure imaginary type (_Imaginary)
> > --> Still not supported by gcc (and llvm), neither in our
> > --> implementation Issues comes from the fact that an imaginary is not
> > --> a complex with
> > real part
> > set to 0
> > --> The same issue with complex multiplication by a real (which is
> > --> split
> > in the
> > frontend, and our implementation hasn't changed it yet)
> > --> Idea: Add an attribute to the Tree complex type which specify pure
> > real / pure
> > imaginary / full complex ?
> >
> > - Fast pattern for IEEE compliant emulated operations
> > --> Not enough time to discuss about it
> >
> > Don't hesitate to add something or bring more precision if you want.
> >
> > As I said at the end of the presentation, we have written a paper
> > which explains our implementation in details. You can find it on the
> > wiki page of the Cauldron
> >
> (https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&tar
> get=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf).
> 
> Thanks for the detailed presentation at the Cauldron.
> 
> My personal summary is that I'm less convinced delaying lowering is the way
> to go.

I personally like the delayed lowering for scalar because it allows us to 
properly
reassociate as a unit. That is to say, it's easier to detect a * b * c when they
are still complex ops. And the late lowering will allow beter codegen than 
today.

However I think we should *unconditionally* not lower them, even in situations
such as a * b  * imag(b). This situation can happen by late optimizations anyway
so it has to be dealt with regardless so I don't think it should punt.

I think you can then conditionally lower if the target does *not* implement the
optab.  i.e. for AArch64 the complex mode wouldn't be useful.

> I do think that if targets implement complex optabs we should use them but
> eventually re-discovering complex operations from lowered form is going to be
> more useful.
> That's because as you said, use of _Complex is limited and
> people inventing their own representation.  SLP vectorization can discover
> some ops already with the limiting factor being that we don't specifically
> search for only complex operations (plus we expose the result as vector
> operations, requiring target support for the vector ops rather than [SD]Cmode
> operations).

I don't think the two are mutually exclusive, I do think we should form complex
instructions from sc

Re: Complex numbers support: discussions summary

[Paul Iannetta via Gcc]

On Tue, Sep 26, 2023 at 09:30:21AM +0200, Richard Biener via Gcc wrote:
> On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc  wrote:
> >
> > Hi,
> >
> > We had very interesting discussions during our presentation with Paul on
> > the
> > support of complex numbers in gcc at the Cauldron.
> >
> > Thank you all for your participation !
> >
> > Here is a small summary from our viewpoint:
> >
> > - Replace CONCAT with a backend defined internal representation in RTL
> > --> No particular problems
> >
> > - Allow backend to write patterns for operation on complex modes
> > --> No particular problems
> >
> > - Conditional lowering depending on whether a pattern exists or not
> > --> Concerns when the vectorization of split complex operations performs
> > better
> > than not vectorized unified complex operations
> >
> > - Centralize complex lowering in cplxlower
> > --> No particular problems if it doesn't prevent IEEE compliance and
> > optimizations (like const folding)
> >
> > - Vectorization of complex operations
> > --> 2 representations (interleaved and separated real/imag): cannot
> > impose one
> > if some machines prefer the other
> > --> Complex are composite modes, the vectorizer assumes that the inner
> > mode is
> > scalar to do some optimizations (which ones ?)
> > --> Mixed split/unified complex operations cannot be vectorized easely
> > --> Assuming that the inner representation of complex vectors is let to
> > target
> > backends, the vectorizer doesn't know it, which prevent some
> > optimizations
> > (which ones ?)
> >
> > - Explicit vectors of complex
> > --> Cplxlower cannot lower it, and moving veclower before cplxlower is a
> > bad
> > idea as it prevents some optimizations
> > --> Teaching cplxlower how to deal with vectors of complex seems to be a
> > reasonable alternative
> > --> Concerns about ABI or indexing if the internal representation is let
> > to the
> > backend and differs from the representation in memory
> >
> > - Impact of the current SLP pattern matching of complex operations
> > --> Only with -ffast-math
> > --> It can match user defined operations (not C99) that can be
> > simplified with a
> > complex instruction
> > --> Dedicated opcode and real vector type choosen VS standard opcode and
> > complex
> > mode in our implementation
> > --> Need to preserve SLP pattern matching as too many applications
> > redefines
> > complex and bypass C99 standard.
> > --> So need to harmonize with our implementation
> >
> > - Support of the pure imaginary type (_Imaginary)
> > --> Still not supported by gcc (and llvm), neither in our implementation
> > --> Issues comes from the fact that an imaginary is not a complex with
> > real part
> > set to 0
> > --> The same issue with complex multiplication by a real (which is split
> > in the
> > frontend, and our implementation hasn't changed it yet)
> > --> Idea: Add an attribute to the Tree complex type which specify pure
> > real / pure
> > imaginary / full complex ?
> >
> > - Fast pattern for IEEE compliant emulated operations
> > --> Not enough time to discuss about it
> >
> > Don't hesitate to add something or bring more precision if you want.
> >
> > As I said at the end of the presentation, we have written a paper which
> > explains
> > our implementation in details. You can find it on the wiki page of the
> > Cauldron
> > (https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf).
> 
> Thanks for the detailed presentation at the Cauldron.
> 
> My personal summary is that I'm less convinced delaying lowering is
> the way to go.

This is not only delayed lowering, if the SPN are there, there is no
lowering at all.

> I do think that if targets implement complex optabs we should use them but
> eventually re-discovering complex operations from lowered form is going to be
> more useful.

I would not be opposed to rediscovering complex operations but I think
that even though, rediscovering a + b, a - b is easy, a * b would
still be doable, but even a / b will be hard.  Even though, I doubt
will see a hardware complex division but who knows.  However, once
lowered, re-associating a * b * c and more complex expressions is going
to be hard.

> That's because as you said, use of _Complex is limited and people
> inventing their own representation.

Yes, this would be a step back at first, but, proper support for
_Complex would probably be an incentive for library writers to take
them into account.

> SLP vectorization can discover some ops
> already with the limiting factor being that we don't specifically search for
> only complex operations (plus we expose the result as vector operations,
> requiring target support for the vector ops rather than [SD]Cmode operations).

Our only concern with SLP is that it only works within loops.  If we
want to re-discover complex numbers we could either add a
dedicat

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Jakub Jelinek via Gcc]

On Tue, Sep 26, 2023 at 10:28:34AM +0200, Florian Weimer via Gcc wrote:
> My understanding of the consensus goes as follows:
> 
> * We want to make some changes in this area for GCC 14.
> * We should do the same thing that Clang does: default to the relevant
>   -Werror= options.

I think it doesn't have to be necessarily using defaulting to -Werror=,
-Werror= involves diagnostic_classify_diagnostic etc.
It could very well be also just testing if the corresponding warning
option isn't explicitly (OPTION_SET_P) disabled and isn't explicitly
-Wno-error=OPTION and c99 or later and conditionally based on that
use error (which would print the [-W...] part though) or warning.
The former would be in system headers too, the latter wouldn't.
We need to decide what exact options we want to turn those errors (and/or
warnings) off or on, -Wno-implicit-int, -w, -Wno-error,
-Wno-error=implicit-int, ...

Jakub

RE: Complex numbers support: discussions summary

[Tamar Christina via Gcc]

> -Original Message-
> From: Gcc  On Behalf
> Of Paul Iannetta via Gcc
> Sent: Tuesday, September 26, 2023 9:54 AM
> To: Richard Biener 
> Cc: Sylvain Noiry ; gcc@gcc.gnu.org;
> sylvain.no...@hotmail.fr
> Subject: Re: Complex numbers support: discussions summary
> 
> On Tue, Sep 26, 2023 at 09:30:21AM +0200, Richard Biener via Gcc wrote:
> > On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc 
> wrote:
> > >
> > > Hi,
> > >
> > > We had very interesting discussions during our presentation with
> > > Paul on the support of complex numbers in gcc at the Cauldron.
> > >
> > > Thank you all for your participation !
> > >
> > > Here is a small summary from our viewpoint:
> > >
> > > - Replace CONCAT with a backend defined internal representation in
> > > RTL
> > > --> No particular problems
> > >
> > > - Allow backend to write patterns for operation on complex modes
> > > --> No particular problems
> > >
> > > - Conditional lowering depending on whether a pattern exists or not
> > > --> Concerns when the vectorization of split complex operations
> > > --> performs
> > > better
> > > than not vectorized unified complex operations
> > >
> > > - Centralize complex lowering in cplxlower
> > > --> No particular problems if it doesn't prevent IEEE compliance and
> > > optimizations (like const folding)
> > >
> > > - Vectorization of complex operations
> > > --> 2 representations (interleaved and separated real/imag): cannot
> > > impose one
> > > if some machines prefer the other
> > > --> Complex are composite modes, the vectorizer assumes that the
> > > --> inner
> > > mode is
> > > scalar to do some optimizations (which ones ?)
> > > --> Mixed split/unified complex operations cannot be vectorized
> > > --> easely Assuming that the inner representation of complex vectors
> > > --> is let to
> > > target
> > > backends, the vectorizer doesn't know it, which prevent some
> > > optimizations
> > > (which ones ?)
> > >
> > > - Explicit vectors of complex
> > > --> Cplxlower cannot lower it, and moving veclower before cplxlower
> > > --> is a
> > > bad
> > > idea as it prevents some optimizations
> > > --> Teaching cplxlower how to deal with vectors of complex seems to
> > > --> be a
> > > reasonable alternative
> > > --> Concerns about ABI or indexing if the internal representation is
> > > --> let
> > > to the
> > > backend and differs from the representation in memory
> > >
> > > - Impact of the current SLP pattern matching of complex operations
> > > --> Only with -ffast-math
> > > --> It can match user defined operations (not C99) that can be
> > > simplified with a
> > > complex instruction
> > > --> Dedicated opcode and real vector type choosen VS standard opcode
> > > --> and
> > > complex
> > > mode in our implementation
> > > --> Need to preserve SLP pattern matching as too many applications
> > > redefines
> > > complex and bypass C99 standard.
> > > --> So need to harmonize with our implementation
> > >
> > > - Support of the pure imaginary type (_Imaginary)
> > > --> Still not supported by gcc (and llvm), neither in our
> > > --> implementation Issues comes from the fact that an imaginary is
> > > --> not a complex with
> > > real part
> > > set to 0
> > > --> The same issue with complex multiplication by a real (which is
> > > --> split
> > > in the
> > > frontend, and our implementation hasn't changed it yet)
> > > --> Idea: Add an attribute to the Tree complex type which specify
> > > --> pure
> > > real / pure
> > > imaginary / full complex ?
> > >
> > > - Fast pattern for IEEE compliant emulated operations
> > > --> Not enough time to discuss about it
> > >
> > > Don't hesitate to add something or bring more precision if you want.
> > >
> > > As I said at the end of the presentation, we have written a paper
> > > which explains our implementation in details. You can find it on the
> > > wiki page of the Cauldron
> > >
> (https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&tar
> get=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf).
> >
> > Thanks for the detailed presentation at the Cauldron.
> >
> > My personal summary is that I'm less convinced delaying lowering is
> > the way to go.
> 
> This is not only delayed lowering, if the SPN are there, there is no lowering 
> at
> all.
> 
> > I do think that if targets implement complex optabs we should use them
> > but eventually re-discovering complex operations from lowered form is
> > going to be more useful.
> 
> I would not be opposed to rediscovering complex operations but I think that
> even though, rediscovering a + b, a - b is easy, a * b would still be doable, 
> but
> even a / b will be hard.  Even though, I doubt will see a hardware complex
> division but who knows.  However, once lowered, re-associating a * b * c and
> more complex expressions is going to be hard.
> 
> > That's because as you said, use of _Complex is limited and people
> > inventi

Re: Complex numbers support: discussions summary

[Paul Iannetta via Gcc]

On Tue, Sep 26, 2023 at 09:28:08AM +, Tamar Christina wrote:
> > -Original Message-
> > From: Gcc  On Behalf
> > Of Paul Iannetta via Gcc
> > Sent: Tuesday, September 26, 2023 9:54 AM
> > To: Richard Biener 
> > Cc: Sylvain Noiry ; gcc@gcc.gnu.org;
> > sylvain.no...@hotmail.fr
> > Subject: Re: Complex numbers support: discussions summary
> > 
> > On Tue, Sep 26, 2023 at 09:30:21AM +0200, Richard Biener via Gcc wrote:
> > > On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc 
> > wrote:
> > > >
> > > > Hi,
> > > >
> > > > We had very interesting discussions during our presentation with
> > > > Paul on the support of complex numbers in gcc at the Cauldron.
> > > >
> > > > Thank you all for your participation !
> > > >
> > > > Here is a small summary from our viewpoint:
> > > >
> > > > - Replace CONCAT with a backend defined internal representation in
> > > > RTL
> > > > --> No particular problems
> > > >
> > > > - Allow backend to write patterns for operation on complex modes
> > > > --> No particular problems
> > > >
> > > > - Conditional lowering depending on whether a pattern exists or not
> > > > --> Concerns when the vectorization of split complex operations
> > > > --> performs
> > > > better
> > > > than not vectorized unified complex operations
> > > >
> > > > - Centralize complex lowering in cplxlower
> > > > --> No particular problems if it doesn't prevent IEEE compliance and
> > > > optimizations (like const folding)
> > > >
> > > > - Vectorization of complex operations
> > > > --> 2 representations (interleaved and separated real/imag): cannot
> > > > impose one
> > > > if some machines prefer the other
> > > > --> Complex are composite modes, the vectorizer assumes that the
> > > > --> inner
> > > > mode is
> > > > scalar to do some optimizations (which ones ?)
> > > > --> Mixed split/unified complex operations cannot be vectorized
> > > > --> easely Assuming that the inner representation of complex vectors
> > > > --> is let to
> > > > target
> > > > backends, the vectorizer doesn't know it, which prevent some
> > > > optimizations
> > > > (which ones ?)
> > > >
> > > > - Explicit vectors of complex
> > > > --> Cplxlower cannot lower it, and moving veclower before cplxlower
> > > > --> is a
> > > > bad
> > > > idea as it prevents some optimizations
> > > > --> Teaching cplxlower how to deal with vectors of complex seems to
> > > > --> be a
> > > > reasonable alternative
> > > > --> Concerns about ABI or indexing if the internal representation is
> > > > --> let
> > > > to the
> > > > backend and differs from the representation in memory
> > > >
> > > > - Impact of the current SLP pattern matching of complex operations
> > > > --> Only with -ffast-math
> > > > --> It can match user defined operations (not C99) that can be
> > > > simplified with a
> > > > complex instruction
> > > > --> Dedicated opcode and real vector type choosen VS standard opcode
> > > > --> and
> > > > complex
> > > > mode in our implementation
> > > > --> Need to preserve SLP pattern matching as too many applications
> > > > redefines
> > > > complex and bypass C99 standard.
> > > > --> So need to harmonize with our implementation
> > > >
> > > > - Support of the pure imaginary type (_Imaginary)
> > > > --> Still not supported by gcc (and llvm), neither in our
> > > > --> implementation Issues comes from the fact that an imaginary is
> > > > --> not a complex with
> > > > real part
> > > > set to 0
> > > > --> The same issue with complex multiplication by a real (which is
> > > > --> split
> > > > in the
> > > > frontend, and our implementation hasn't changed it yet)
> > > > --> Idea: Add an attribute to the Tree complex type which specify
> > > > --> pure
> > > > real / pure
> > > > imaginary / full complex ?
> > > >
> > > > - Fast pattern for IEEE compliant emulated operations
> > > > --> Not enough time to discuss about it
> > > >
> > > > Don't hesitate to add something or bring more precision if you want.
> > > >
> > > > As I said at the end of the presentation, we have written a paper
> > > > which explains our implementation in details. You can find it on the
> > > > wiki page of the Cauldron
> > > >
> > (https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&tar
> > get=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf).
> > >
> > > Thanks for the detailed presentation at the Cauldron.
> > >
> > > My personal summary is that I'm less convinced delaying lowering is
> > > the way to go.
> > 
> > This is not only delayed lowering, if the SPN are there, there is no 
> > lowering at
> > all.
> > 
> > > I do think that if targets implement complex optabs we should use them
> > > but eventually re-discovering complex operations from lowered form is
> > > going to be more useful.
> > 
> > I would not be opposed to rediscovering complex operations but I think that
> > even though, rediscovering a + b, a - b is easy, a * b would

Re: Complex numbers support: discussions summary

[Paul Iannetta via Gcc]

On Tue, Sep 26, 2023 at 08:29:16AM +, Tamar Christina via Gcc wrote:
> Hi,
> 
> I tried to find you two on Sunday but couldn't locate you. Thanks for the 
> presentation!

Yes, sadly we could not attend on Sunday because we wanted to be back
for Monday.

> > >
> > > We had very interesting discussions during our presentation with Paul
> > > on the support of complex numbers in gcc at the Cauldron.
> > >
> > > Thank you all for your participation !
> > >
> > > Here is a small summary from our viewpoint:
> > >
> > > - Replace CONCAT with a backend defined internal representation in RTL
> > > --> No particular problems
> > >
> > > - Allow backend to write patterns for operation on complex modes
> > > --> No particular problems
> > >
> > > - Conditional lowering depending on whether a pattern exists or not
> > > --> Concerns when the vectorization of split complex operations
> > > --> performs
> > > better
> > > than not vectorized unified complex operations
> > >
> > > - Centralize complex lowering in cplxlower
> > > --> No particular problems if it doesn't prevent IEEE compliance and
> > > optimizations (like const folding)
> > >
> > > - Vectorization of complex operations
> > > --> 2 representations (interleaved and separated real/imag): cannot
> > > impose one
> > > if some machines prefer the other
> > > --> Complex are composite modes, the vectorizer assumes that the inner
> > > mode is
> > > scalar to do some optimizations (which ones ?)
> > > --> Mixed split/unified complex operations cannot be vectorized easely
> > > --> Assuming that the inner representation of complex vectors is let
> > > --> to
> > > target
> > > backends, the vectorizer doesn't know it, which prevent some
> > > optimizations
> > > (which ones ?)
> > >
> > > - Explicit vectors of complex
> > > --> Cplxlower cannot lower it, and moving veclower before cplxlower is
> > > --> a
> > > bad
> > > idea as it prevents some optimizations
> > > --> Teaching cplxlower how to deal with vectors of complex seems to be
> > > --> a
> > > reasonable alternative
> > > --> Concerns about ABI or indexing if the internal representation is
> > > --> let
> > > to the
> > > backend and differs from the representation in memory
> > >
> > > - Impact of the current SLP pattern matching of complex operations
> > > --> Only with -ffast-math
> > > --> It can match user defined operations (not C99) that can be
> > > simplified with a
> > > complex instruction
> > > --> Dedicated opcode and real vector type choosen VS standard opcode
> > > --> and
> > > complex
> > > mode in our implementation
> > > --> Need to preserve SLP pattern matching as too many applications
> > > redefines
> > > complex and bypass C99 standard.
> > > --> So need to harmonize with our implementation
> > >
> > > - Support of the pure imaginary type (_Imaginary)
> > > --> Still not supported by gcc (and llvm), neither in our
> > > --> implementation Issues comes from the fact that an imaginary is not
> > > --> a complex with
> > > real part
> > > set to 0
> > > --> The same issue with complex multiplication by a real (which is
> > > --> split
> > > in the
> > > frontend, and our implementation hasn't changed it yet)
> > > --> Idea: Add an attribute to the Tree complex type which specify pure
> > > real / pure
> > > imaginary / full complex ?
> > >
> > > - Fast pattern for IEEE compliant emulated operations
> > > --> Not enough time to discuss about it
> > >
> > > Don't hesitate to add something or bring more precision if you want.
> > >
> > > As I said at the end of the presentation, we have written a paper
> > > which explains our implementation in details. You can find it on the
> > > wiki page of the Cauldron
> > >
> > (https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&tar
> > get=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf).
> > 
> > Thanks for the detailed presentation at the Cauldron.
> > 
> > My personal summary is that I'm less convinced delaying lowering is the way
> > to go.
> 
> I personally like the delayed lowering for scalar because it allows us to 
> properly
> reassociate as a unit. That is to say, it's easier to detect a * b * c when 
> they
> are still complex ops. And the late lowering will allow beter codegen than 
> today.
> 
> However I think we should *unconditionally* not lower them, even in situations
> such as a * b  * imag(b). This situation can happen by late optimizations 
> anyway
> so it has to be dealt with regardless so I don't think it should punt.
> 
> I think you can then conditionally lower if the target does *not* implement 
> the
> optab.  i.e. for AArch64 the complex mode wouldn't be useful.
> 

Indeed, our current approach in the vectorizer works only if the
complex scalar patterns exist as well, and I agree that it would be
better to if the absence of either scalar or vector patterns would not
prevent any optimizations.

Keeping everything unified unti

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Florian Weimer via Gcc]

* Jakub Jelinek:

> On Tue, Sep 26, 2023 at 10:28:34AM +0200, Florian Weimer via Gcc wrote:
>> My understanding of the consensus goes as follows:
>> 
>> * We want to make some changes in this area for GCC 14.
>> * We should do the same thing that Clang does: default to the relevant
>>   -Werror= options.
>
> I think it doesn't have to be necessarily using defaulting to -Werror=,
> -Werror= involves diagnostic_classify_diagnostic etc.
> It could very well be also just testing if the corresponding warning
> option isn't explicitly (OPTION_SET_P) disabled and isn't explicitly
> -Wno-error=OPTION and c99 or later and conditionally based on that
> use error (which would print the [-W...] part though) or warning.
> The former would be in system headers too, the latter wouldn't.
> We need to decide what exact options we want to turn those errors (and/or
> warnings) off or on, -Wno-implicit-int, -w, -Wno-error,
> -Wno-error=implicit-int, ...

I didn't mean to be prescriptive about implementation details, sorry.

With Clang, -w and -Wno-error have no effect on those error-by-default
warnings, too.  And I don't think Clang supports suppressing warnings
from system headers.

Thanks,
Florian

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Jeff Law via Gcc]

On 9/26/23 02:28, Florian Weimer via Gcc wrote:

My understanding of the consensus goes as follows:

* We want to make some changes in this area for GCC 14.
* We should do the same thing that Clang does: default to the relevant
   -Werror= options.
* Unlike regular warnings, these warnings-as-errors should also apply
   to system headers.
* At least implict-int and implicit-function-declaration should be
   upgraded to errors in this way.
* It's too early to make the () changes and bool-as-keyword from C2X
   for GCC 14.
* We should fix the missing scope of the int-conversion warnings
   (PR109827).  Likweise for incompatible-pointer-types (PR109826).

Is this summary accurate?
I wasn't there, so I can't attest to accuracy.  It does look like a 
reasonable plan for gcc-14 though.




I think the open issues are:

* Do we want to implement something else beside implicit-int and
   implicit-function-declaration?  (Candidates are int-conversion and
   incompatible-pointer-types, and the void vs non-void part of
   return-type, maybe others as previously discussed on the list.)
* How do we divide up the test suite cleanup work?
Not to open a can of worms, but shouldn't these be evaluated along the 
same basic criteria?  ie, what's Clang doing here, are these 
warnings-as-errors and thus apply to system headers, etc.  ANd the 
biggie, do any of these issues tend to mask correctness errors in the 
wild at a level roughly similar to implicit 
int/implicit-function-declaration?


Jeff

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Florian Weimer via Gcc]

* Jeff Law:

>> I think the open issues are:
>> * Do we want to implement something else beside implicit-int and
>>implicit-function-declaration?  (Candidates are int-conversion and
>>incompatible-pointer-types, and the void vs non-void part of
>>return-type, maybe others as previously discussed on the list.)
>> * How do we divide up the test suite cleanup work?

> Not to open a can of worms, but shouldn't these be evaluated along the
> same basic criteria?  ie, what's Clang doing here, are these
> warnings-as-errors and thus apply to system headers, etc.  ANd the
> biggie, do any of these issues tend to mask correctness errors in the
> wild at a level roughly similar to implicit
> int/implicit-function-declaration?

At present, it is not possible to evaluate them using the same basic
criteria because we don't have the answer to your last question.  I have
an instrumented compiler for -Wint-conversion, but have not had a chance
yet to run a distribution rebuild with it.

Thanks,
Florian

Re: Complex numbers support: discussions summary

[Joseph Myers]

On Mon, 25 Sep 2023, Sylvain Noiry via Gcc wrote:

> --> Idea: Add an attribute to the Tree complex type which specify pure real /
> pure
>    imaginary / full complex ?

If you start from the implementation approach of lowering imaginary type 
operations in the front end, a flag on a REAL_TYPE would seem natural (and 
then the rest of the compiler could treat such types the same as other 
real types with the same machine modes).

That would however mean that e.g. conversions to/from imaginary types in 
the front end are not the same thing as what you get from middle-end 
conversions (the former would apply the rules that converting imaginary to 
real or real to imaginary produces zero while preserving side effects from 
the expression converted; the latter would be a no-op conversion if the 
machine modes are the same), which has the potential to be confusing.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Complex numbers support: discussions summary

[Toon Moene]

On 9/26/23 09:30, Richard Biener via Gcc wrote:


On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc  wrote:



As I said at the end of the presentation, we have written a paper which
explains
our implementation in details. You can find it on the wiki page of the
Cauldron
(https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf).


Thanks for the detailed presentation at the Cauldron.

My personal summary is that I'm less convinced delaying lowering is
the way to go.


Thanks Sylvain for the quick summary of the discussion - it helps a 
great deal now that the discussion is still fresh in our memory.


Some thought I came up with (of course, only after the end of the 
conference):


In what way is the handling of the complex type different from that of 
the 128 bit real (i.e., float) type ?


Both are not implemented on most architectures; on most they require two 
registers (or possibly two memory location that do not necessarily have 
to be adjacent) to be implemented.


Yet both are supported by the middle end - consider the clear 
equivalence of the handling of variables a and b when looking at the 
result of -fdump-tree-ssa (on x86_64) for:


cat 128.f90
parameter (iq=kind(1q0))
real(kind=iq) :: a, b
read*, a, b
print*, a / b
end

and:

cat complex.f90
complex a,b
read*,a,b
print*,a/b
end

Hope this helps for a continuing fruitful discussion.

Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Sam James via Gcc]

Florian Weimer via Gcc  writes:

> My understanding of the consensus goes as follows:
>
> * We want to make some changes in this area for GCC 14.
> * We should do the same thing that Clang does: default to the relevant
>   -Werror= options.
> * Unlike regular warnings, these warnings-as-errors should also apply
>   to system headers.
> * At least implict-int and implicit-function-declaration should be
>   upgraded to errors in this way.
> * It's too early to make the () changes and bool-as-keyword from C2X
>   for GCC 14.
> * We should fix the missing scope of the int-conversion warnings
>   (PR109827).  Likweise for incompatible-pointer-types (PR109826).
>
> Is this summary accurate?
>

I wasn't there, but this reflects my understanding & what I would've
said if I could've attended.

> I think the open issues are:
>
> * Do we want to implement something else beside implicit-int and
>   implicit-function-declaration?  (Candidates are int-conversion and
>   incompatible-pointer-types, and the void vs non-void part of
>   return-type, maybe others as previously discussed on the list.)

Ideally, I'd like both int-conversion + incompatible-pointer-types in
this cycle, but if we have to defer one, I'd say to keep int-conversion.

A lot of the low hanging fruit is already fixed there, with the only
big remaining blocker being Vala (which is a
compiler/transpiler). They've indicated they're not that fussed
unless/until GCC changes.

Putting it another way: I don't think waiting a year or two
would actually help the situation much.

> * How do we divide up the test suite cleanup work?

Once there's some patches to work with, I'm happy to do a good
chunk (obviously).

IIRC Jakub and others indicated that the priority is to preserve
the test cases (and hence pass appropriate flags) rather than fix them
up, to avoid inadvertently testing the wrong thing.

>
> Thanks,
> Florian

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Sam James via Gcc]

Jeff Law via Gcc  writes:

> On 9/26/23 02:28, Florian Weimer via Gcc wrote:
>> My understanding of the consensus goes as follows:
>> * We want to make some changes in this area for GCC 14.
>> * We should do the same thing that Clang does: default to the relevant
>>-Werror= options.
>> * Unlike regular warnings, these warnings-as-errors should also apply
>>to system headers.
>> * At least implict-int and implicit-function-declaration should be
>>upgraded to errors in this way.
>> * It's too early to make the () changes and bool-as-keyword from C2X
>>for GCC 14.
>> * We should fix the missing scope of the int-conversion warnings
>>(PR109827).  Likweise for incompatible-pointer-types (PR109826).
>> Is this summary accurate?
> I wasn't there, so I can't attest to accuracy.  It does look like a
> reasonable plan for gcc-14 though.
>
>> I think the open issues are:
>> * Do we want to implement something else beside implicit-int and
>>implicit-function-declaration?  (Candidates are int-conversion and
>>incompatible-pointer-types, and the void vs non-void part of
>>return-type, maybe others as previously discussed on the list.)
>> * How do we divide up the test suite cleanup work?
> Not to open a can of worms, but shouldn't these be evaluated along the
> same basic criteria?  ie, what's Clang doing here, are these
> warnings-as-errors and thus apply to system headers, etc.  ANd the
> biggie, do any of these issues tend to mask correctness errors in the
> wild at a level roughly similar to implicit
> int/implicit-function-declaration?

My experience from doing the big rebuilds in Gentoo and working on
patches is that int-conversion often comes up with completely broken code
like wrong strerror_r variant (glibc vs musl) or with structs being
initialised with the wrong members (not using C99 desig. initialisers
and then differences with padding or similar). I don't think I can
recall a harmless hit.

Incompatible pointer types are a mix - sometimes it's harmless, but
a lot of the infringers aren't great (again often indicating wrong
prototypes being used or missing feature test macros). It's helped
to find a lot of typos as well. The only real snag (which isn't
a big deal IMO) is that it'll flag up attribute mismatches for
function pointer types, at least with Clang, but that's not a big
deal.

Clang has done both of these (technically Clang has only done
incompatible *function* pointer types rather than all incompatible
pointer types, at least for now though).

>
> Jeff

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Arsen Arsenović via Gcc]

Sam James via Gcc  writes:

> Florian Weimer via Gcc  writes:
>
>> My understanding of the consensus goes as follows:
>>
>> * We want to make some changes in this area for GCC 14.
>> * We should do the same thing that Clang does: default to the relevant
>>   -Werror= options.
>> * Unlike regular warnings, these warnings-as-errors should also apply
>>   to system headers.
>> * At least implict-int and implicit-function-declaration should be
>>   upgraded to errors in this way.
>> * It's too early to make the () changes and bool-as-keyword from C2X
>>   for GCC 14.
>> * We should fix the missing scope of the int-conversion warnings
>>   (PR109827).  Likweise for incompatible-pointer-types (PR109826).
>>
>> Is this summary accurate?
>>
>
> I wasn't there, but this reflects my understanding & what I would've
> said if I could've attended.
>
>> I think the open issues are:
>>
>> * Do we want to implement something else beside implicit-int and
>>   implicit-function-declaration?  (Candidates are int-conversion and
>>   incompatible-pointer-types, and the void vs non-void part of
>>   return-type, maybe others as previously discussed on the list.)
>
> Ideally, I'd like both int-conversion + incompatible-pointer-types in
> this cycle, but if we have to defer one, I'd say to keep int-conversion.

+1, this seems reasonable.  I'm not sure I can imagine any even
half-legitimate use for falling off the end of functions and similar, so
perhaps we should also take return-type?  Is that part of C23?

> A lot of the low hanging fruit is already fixed there, with the only
> big remaining blocker being Vala (which is a
> compiler/transpiler). They've indicated they're not that fussed
> unless/until GCC changes.
>
> Putting it another way: I don't think waiting a year or two
> would actually help the situation much.

Yes, at best it helps with the schedule.

>> * How do we divide up the test suite cleanup work?
>
> Once there's some patches to work with, I'm happy to do a good
> chunk (obviously).
>
> IIRC Jakub and others indicated that the priority is to preserve
> the test cases (and hence pass appropriate flags) rather than fix them
> up, to avoid inadvertently testing the wrong thing.

We could possibly even automate that, by checking what new errors
appeared per testcase and inverting them.

>>
>> Thanks,
>> Florian


-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Incremental LTO Project

[Thomas Schwinge]

Hi!

Four things:

On 2023-09-10T23:25:06+0200, Jan Hubicka via Gcc  wrote:
>> On 2023-09-07T19:00:49-0400, James Hu via Gcc  wrote:
>> > I noticed that adding incremental LTO was a GSoC project that was not
>> > claimed this cycle (
>> > https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-compiler-collection-gcc).
>> > I was curious about working on this project, but wanted to check on the
>> > state of the project.
>>
>> Thanks for your interest!  (... as a potential contributor, I presume?)
>>
>> > Has it already been completed? Is someone actively
>> > working on it?
>>
>> Yesterday, when browsing the schedule of the GNU Tools Cauldron 2023,
>> , I noticed there's going to be a
>> presentation on "Incremental LTO in GCC" (Michal Jireš),
>> .

1. Was nice to meet you (Honza, Michal) at the Cauldron, attending the
"Incremental LTO in GCC" presentation.  (James: recording should become
available soonish.)

> Indeed Michal Jires (who is my student at Charles University) did a lot
> of work on incremental LTO.  He is finishing his second bachelor in
> physics and then we plan to start working towards contributing it to the
> mainline.

Great!

> His imlementation is described in thesis
> https://dspace.cuni.cz/bitstream/handle/20.500.11956/183051/130360194.pdf?sequence=1

2. Talking to you after the presentation, I had mentioned that I had
failed to understand how the new partitioning scheme works, when reading
Michal's thesis on my way to the Cauldron.  I'm happy to report that upon
re-reading it on my way back home, I then did manage to understand it.
;-)

3. I had suggested that in addition to compilation flags (which you have
covered, per my understanding) also the specific compiler builds should
probably be taken into account (by means of 'cc1' etc. checksums, for
example?), so that the cache doesn't return out-of-date results in that
regard.  Now I had the idea whether we maybe could simply use/modify
'ccache' for that chaching aspect, as it does exactly that: maintain a
persistent cache, with user-configurable size, stale objects pruning,
etc., and takes care that no stale cached objects are returned to the
user.  I've not spent any more detailed thoughts on that, however.

> This is just a start of the project, further improvemnts will be welcome

Which brings us to 4.:

On 2023-09-08T07:26:20-0400, James Hu via Gcc  wrote:
> Ah, I see. I was interested as a contributor but outside of the official
> GSoC program. But I'm assuming that because there is a talk on incremental
> LTO, it has already been implemented, correct?

Is there anything that James could work on -- without conflicting with
Michal's ongoing work?  (Note that I'm just the hopefully helpful
messenger here; don't know James personally.)

James, I suppose it'd help if you sketched what's interesting to you in a
bit more detail than just "incremental LTO", and the amount of work/time
you'll be able to invest, roughly.


Grüße
 Thomas


>> > If not, what would be the appropriate method to contact the
>> > mentor (Jan Hubička)?
>>
>> He's reading this list, but I've now also put Honza in CC.
>>
>>
>> Grüße
>>  Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Question about merging if-else blocks

[Hanke Zhang via Gcc]

Hi, I have recently been working on merging if-else statement blocks,
and I found a rather bizarre phenomenon that I would like to ask
about.
A rough explanation is that for two consecutive if-else blocks, if
their if statements are exactly the same, they should be merged, like
the following program:

int a = atoi(argv[1]);
if (a) {
  printf("if 1");
} else {
  printf("else 1");
}
if (a) {
  printf("if 2");
} else {
  printf("else 2");
}

After using the -O3 -flto optimization option, it can be optimized as follows:

int a = atoi(argv[1]);
if (a) {
  printf("if 1");
  printf("if 2");
} else {
  printf("else 1");
  printf("else 2");
}

But `a` here is a local variable. If I declare a as a global variable,
it cannot be optimized as above. I would like to ask why this is? And
is there any solution?

Thanks.
Hanke Zhang.

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Florian Weimer via Gcc]

* Arsen Arsenović via Gcc:

> Sam James via Gcc  writes:
>
>> Florian Weimer via Gcc  writes:
>>
>>> My understanding of the consensus goes as follows:
>>>
>>> * We want to make some changes in this area for GCC 14.
>>> * We should do the same thing that Clang does: default to the relevant
>>>   -Werror= options.
>>> * Unlike regular warnings, these warnings-as-errors should also apply
>>>   to system headers.
>>> * At least implict-int and implicit-function-declaration should be
>>>   upgraded to errors in this way.
>>> * It's too early to make the () changes and bool-as-keyword from C2X
>>>   for GCC 14.
>>> * We should fix the missing scope of the int-conversion warnings
>>>   (PR109827).  Likweise for incompatible-pointer-types (PR109826).
>>>
>>> Is this summary accurate?
>>>
>>
>> I wasn't there, but this reflects my understanding & what I would've
>> said if I could've attended.
>>
>>> I think the open issues are:
>>>
>>> * Do we want to implement something else beside implicit-int and
>>>   implicit-function-declaration?  (Candidates are int-conversion and
>>>   incompatible-pointer-types, and the void vs non-void part of
>>>   return-type, maybe others as previously discussed on the list.)
>>
>> Ideally, I'd like both int-conversion + incompatible-pointer-types in
>> this cycle, but if we have to defer one, I'd say to keep int-conversion.
>
> +1, this seems reasonable.  I'm not sure I can imagine any even
> half-legitimate use for falling off the end of functions and similar, so
> perhaps we should also take return-type?  Is that part of C23?

Falling of the end of the function is legitimate if a no-return function
is called and not annotated as such, among other things.  I don't think
we should warn or error for that by default.

The issue I'm concerned about is about “return;” in a function not
returning void, or “return expr;” in a function returning void.  This
looks like related to implict int return types for functions.  It's not
part of C99.  There is no separate -W switch to control this warning.
It is on by default (as required by C99), unlike other aspects of
-Wreturn-type.

Thanks,
Florian

Re: Question about merging if-else blocks

[Marc Glisse via Gcc]

On Wed, 27 Sep 2023, Hanke Zhang via Gcc wrote:


Hi, I have recently been working on merging if-else statement blocks,
and I found a rather bizarre phenomenon that I would like to ask
about.
A rough explanation is that for two consecutive if-else blocks, if
their if statements are exactly the same, they should be merged, like
the following program:

int a = atoi(argv[1]);
if (a) {
 printf("if 1");
} else {
 printf("else 1");
}
if (a) {
 printf("if 2");
} else {
 printf("else 2");
}

After using the -O3 -flto optimization option, it can be optimized as follows:

int a = atoi(argv[1]);
if (a) {
 printf("if 1");
 printf("if 2");
} else {
 printf("else 1");
 printf("else 2");
}

But `a` here is a local variable. If I declare a as a global variable,
it cannot be optimized as above. I would like to ask why this is? And
is there any solution?


If 'a' is a global variable, how do you know 'printf' doesn't modify its 
value? (you could know it for printf, but it really depends on the 
function that is called)


--
Marc Glisse

Re: Question about merging if-else blocks

[Hanke Zhang via Gcc]

Thanks! I understand what you mean, then can I think that if the
function here is not an external function, but a function visible to
the compiler and the function doesn't modify `a`, then these two
blocks can be merged?

Marc Glisse  于2023年9月27日周三 12:51写道：
>
> On Wed, 27 Sep 2023, Hanke Zhang via Gcc wrote:
>
> > Hi, I have recently been working on merging if-else statement blocks,
> > and I found a rather bizarre phenomenon that I would like to ask
> > about.
> > A rough explanation is that for two consecutive if-else blocks, if
> > their if statements are exactly the same, they should be merged, like
> > the following program:
> >
> > int a = atoi(argv[1]);
> > if (a) {
> >  printf("if 1");
> > } else {
> >  printf("else 1");
> > }
> > if (a) {
> >  printf("if 2");
> > } else {
> >  printf("else 2");
> > }
> >
> > After using the -O3 -flto optimization option, it can be optimized as 
> > follows:
> >
> > int a = atoi(argv[1]);
> > if (a) {
> >  printf("if 1");
> >  printf("if 2");
> > } else {
> >  printf("else 1");
> >  printf("else 2");
> > }
> >
> > But `a` here is a local variable. If I declare a as a global variable,
> > it cannot be optimized as above. I would like to ask why this is? And
> > is there any solution?
>
> If 'a' is a global variable, how do you know 'printf' doesn't modify its
> value? (you could know it for printf, but it really depends on the
> function that is called)
>
> --
> Marc Glisse