Re: Changes to allow PowerPC to change the long double type to use the IEEE 128-bit floating point format

[Thomas König]

Am 10.08.20 um 18:53 schrieb Michael Meissner:

IMHO, changing the default is only appropriate for times like a distribution
major number changes, where backwards and forwards compatibility is carefully
controlled.  But before we can contemplate doing this, we need the ability to
change the default and have it all work together.


That is, of course, true.

However, we should already think ahead.  If this change is done the
way you describe, where we would just change REAL(KIND=16) from
__ibm128 to __float128, this is a binary incompatible change,
and libgfortran needs a new major revision number on POWER. I see
no way around that.

Best regards

Thomas

Re: Clobber REG_CC only for some constraint alternatives?

[Pip Cet via Gcc]

On Sat, Aug 15, 2020 at 12:30 AM Segher Boessenkool
 wrote:
> On Fri, Aug 14, 2020 at 05:47:02PM +, Pip Cet wrote:
> > On Fri, Aug 14, 2020 at 4:24 PM Segher Boessenkool
> >  wrote:
> > > If you want to say some alternative does not clobber anything, just use
> > > the constraint "X" for that alternative.
> >
> > Just to clarify, such clobbers would still show up in RTL, right?
>
> Yes, as
>
>   (clobber (scratch:CC))
>
> (or whatever the mode is).  No register will be allocated to it.  You
> can do a define_split splitting it into the form without clobber, if
> you want?  (You can "split" to just one insn fine.)  It's neatest when
> written as a define_insn_and_split.

That does sound like a neat solution for leaving the current patterns
largely intact, thanks! I'll try both variants, both and without the
define_split.

> > What I'm currently doing is this:
> >
> > (define_split
> >   [(set (match_operand 0 "nonimmediate_operand")
> > (match_operand 1 "nox_general_operand"))]
> >   "reload_completed && mov_clobbers_cc (insn, operands)"
> >   [(parallel [(set (match_dup 0) (match_dup 1))
> >   (clobber (reg:CC REG_CC))])])
> >
> > which, if I understand correctly, introduces the parallel-clobber
> > expression only when necessary, at the same time as post-reload
> > splitters introduce REG_CC references. Is that correct?
>
> Yes.  And this will work correctly if somehow you ensure that REG_CC
> isn't live anywhere you introduce such a clobber.

IIUC, the idea is that references to REG_CC, except for clobbers, are
only introduced in the post-reload split pass, so it cannot be live
before our define_split runs. Does that make sense?

Re: Peephole optimisation: isWhitespace()

[Nathan Sidwell]

On 8/14/20 12:43 PM, Stefan Kanthak wrote:

Hi @ll,

in his ACM queue article ,
Matt Godbolt used the function

| bool isWhitespace(char c)
| {
| return c == ' '
|   || c == '\r'
|   || c == '\n'
|   || c == '\t';
| }

as an example, for which GCC 9.1 emits the following assembly for AMD64
processors (see ):

|xoreax, eax  ; result = false
|cmpdil, 32   ; is c > 32
|ja .L4   ; if so, exit with false
|movabs rax, 4294977024   ; rax = 0x12600
|shrx   rax, rax, rdi ; rax >>= c
|andeax, 1; result = rax & 1
|.L4:
|ret

This code is but not optimal!


What evidence do you have that your alternative sequence performs better?  Have 
you benchmarked it?  (I tried, but your code doesn't assemble)


It is more instructions and cannot speculate past the setnz (As I understand it, 
x86_64 speculates branch instructions, but doesn't speculate cmov -- so 
perversely branches are faster!)



The following equivalent and branchless code works on i386 too,
it needs neither an AMD64 processor nor the SHRX instruction,
which is not available on older processors:




  movecx, edi
  moveax, 2600h; eax = (1 << '\r') | (1 << '\n') | (1 << 
'\t')
  test   cl, cl
  setnz  al; eax |= (c != '\0')
  shreax, cl   ; eax >>= (c % ' ')


^^ operand type mismatch on this instruction


  xoredx, edx
  cmpecx, 33   ; CF = c <= ' '
  adcedx, edx  ; edx = (c <= ' ')
  andeax, edx
  ret


regards
Stefan Kanthak




--
Nathan Sidwell

gcc-10-20200815 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20200815 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20200815/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision db6878c043d87fab80bf5906824661d54f20096b

You'll find:

 gcc-10-20200815.tar.xz   Complete GCC

  SHA256=38e6488bd93afbf20b21fb4f5ac6fb2775030500f09c0f4974a7acb9779c9653
  SHA1=7ae4dd19139044f732d44a3ff548e7fb0bbe822b

Diffs from 10-20200808 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Clobber REG_CC only for some constraint alternatives?

[Segher Boessenkool]

On Sat, Aug 15, 2020 at 10:18:27AM +, Pip Cet wrote:
> > > What I'm currently doing is this:
> > >
> > > (define_split
> > >   [(set (match_operand 0 "nonimmediate_operand")
> > > (match_operand 1 "nox_general_operand"))]
> > >   "reload_completed && mov_clobbers_cc (insn, operands)"
> > >   [(parallel [(set (match_dup 0) (match_dup 1))
> > >   (clobber (reg:CC REG_CC))])])
> > >
> > > which, if I understand correctly, introduces the parallel-clobber
> > > expression only when necessary, at the same time as post-reload
> > > splitters introduce REG_CC references. Is that correct?
> >
> > Yes.  And this will work correctly if somehow you ensure that REG_CC
> > isn't live anywhere you introduce such a clobber.
> 
> IIUC, the idea is that references to REG_CC, except for clobbers, are
> only introduced in the post-reload split pass, so it cannot be live
> before our define_split runs. Does that make sense?

Yes, it does.  It has some huge restrictions (using the reg in inline
assembler can never work reliably, for example, so you'll have to
disallow that).  And earlier passes (like combine) cannot optimise this,
etc.  But it is a pretty straightforward way to move from CC0 to the
modern world!


Segher

Re: Clobber REG_CC only for some constraint alternatives?

[Hans-Peter Nilsson]

On Fri, 14 Aug 2020, Senthil Kumar Selvaraj via Gcc wrote:
> As you can deduce from the (set_attr "cc" ..), only constraint
> alternatives 0,2,3 and 6 clobber CC - others leave it unchanged.

Yes, I recognize that.

> My first version of the port adds a post-reload splitter that adds a
> (clobber (reg:CC REG_CC)) unconditionally, and it appears to work.

Ouch, temporarily lying to gcc here.

> If I
> do want to add the clobber conditionally, would something like the below
> be a good way to do it (get_cc_reg_clobber_rtx returns either const0_rtx
> or cc_reg_rtx based on get_attr_cc (insn))? Or is there a better/cleaner way?

I suggest having a look at what I did for the CRIS port.
Check the git history.

In short:
- Add the clobber initially, to *all* patterns.
- Add postreload splitters for the special combinations that
don't clobber CC (ones without clobbering CC).
- Use the old "cc" attribute to control and generate
clobber/useful CC-setting alternatives (for various new CC_
modes) with use of define_subst.

No regressions in CC quality (with one pending patch).

brgds, H-P