Clobber REG_CC only for some constraint alternatives?

[Senthil Kumar Selvaraj via Gcc]

Hi,

  I'm working on porting AVR to MODE_CC, and there are quite a few
  patterns that clobber the condition code reg only for certain
  constraint alternatives. For e.g.,

(define_insn "mov_insn"
  [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d,Qm   ,r 
,q,r,*r")
(match_operand:ALL1 1 "nox_general_operand"   "r Y00,n Ynn,r 
Y00,Qm,r,q,i"))]
 "register_operand (operands[0], mode)
 || reg_or_0_operand (operands[1], mode)"
 {
  return output_movqi (insn, operands, NULL);
 }
 [(set_attr "length" "1,1,5,5,1,1,4")
 (set_attr "adjust_len" "mov8")
 (set_attr "cc" "ldi,none,clobber,clobber,none,none,clobber")])

As you can deduce from the (set_attr "cc" ..), only constraint
alternatives 0,2,3 and 6 clobber CC - others leave it unchanged.

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. 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?

(define_insn_and_split "mov_insn"
  [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d,Qm   ,r 
,q,r,*r")
(match_operand:ALL1 1 "nox_general_operand"   "r Y00,n Ynn,r 
Y00,Qm,r,q,i"))]
  "register_operand (operands[0], mode)
|| reg_or_0_operand (operands[1], mode)"
  "#"
  "&& reload_completed"
  [(parallel [(set (match_dup 0)
   (match_dup 1))
  (clobber (match_dup 2))])]
  {
operands[2] = get_cc_reg_clobber_rtx (curr_insn);
  }
  [(set_attr "cc" "ldi,none,clobber,clobber,none,none,clobber")])

(define_insn "*mov_insn_clobber_flags"
  [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,Qm   ,r ,*r")
(match_operand:ALL1 1 "nox_general_operand"   "r Y00,r Y00,Qm,i"))
   (clobber (reg:CC REG_CC))]
  "(register_operand (operands[0], mode)
|| reg_or_0_operand (operands[1], mode))
   && reload_completed"
  {
return output_movqi (insn, operands, NULL);
  }
  [(set_attr "length" "1,5,5,4")
   (set_attr "adjust_len" "mov8")])

(define_insn "*mov_insn_noclobber_flags"
  [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d   ,q,r")
(match_operand:ALL1 1 "nox_general_operand"   "r,n Ynn,r,q"))
   (clobber (const_int 0))]
  "(register_operand (operands[0], mode)
|| reg_or_0_operand (operands[1], mode))
   && reload_completed"
  {
return output_movqi (insn, operands, NULL);
  }
  [(set_attr "length" "1,1,1,1")
   (set_attr "adjust_len" "mov8")])

Regards
Senthil

Intel AMX programming model discussion

[Luo, Yuanke via Gcc]

Hi,
Intel Advanced Matrix Extensions (Intel AMX) is a new programming paradigm 
consisting of two components: a set of 2-dimensional registers (tiles) 
representing sub-arrays from a larger 2-dimensional memory image, and 
accelerators able to operate on tiles. Capability of Intel AMX implementation 
is enumerated by palettes. Two palettes are supported: palette 0 represents the 
initialized state and palette 1 consists of 8 tile registers of up to 1 KB 
size, which is controlled by a tile control register.
The instruction manual is posted at 
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html.
The AMX abi proposal is posted at 
https://groups.google.com/g/x86-64-abi/c/NRejFm7pwb4.
This email is to discuss the programming model for AMX. Florian has introduced 
the matrix type and intrinsics in LLVM community. We'd like to adopt some ideas 
from it.
We propose for the AMX programming model at 
http://lists.llvm.org/pipermail/llvm-dev/2020-August/144302.html. Comments are 
welcome.

Thanks
Yuanke

Re: Has FSF stopped processing copyright paperwork?

[Kaylee Blake via Gcc]

On 7/8/20 10:41 pm, H.J. Lu wrote:
> On Tue, May 5, 2020 at 6:42 PM Kaylee Blake  wrote:
>>
>> On 2/5/20 11:49 pm, H.J. Lu wrote:
>>> On Wed, Mar 18, 2020 at 6:46 PM Kaylee Blake via Binutils
>>>  wrote:

 On 19/3/20 12:02 pm, H.J. Lu wrote:
> Kaylee, is your paper work with FSF in order? I will submit the updated
> patch set after your paper is on file with FSF.

 I'm waiting on a response from them at the moment.

>>>
>>> Hi Kaylee,
>>>
>>> Any update on your paper work with FSF?
>>>
>>
>> Still waiting; apparently their work process has been dramatically
>> slowed by the whole COVID-19 situation.
>>
>> --
>> Kaylee Blake 
>> C is the worst language, except for all the others.
> 
> Hi,
> 
> I submitted a set of binutils patches:
> 
> https://sourceware.org/pipermail/binutils/2020-March/13.html
> 
> including contribution from Kaylee Blake .
> Can someone check if Kaylee's paperwork is on file with FSF?
> 
> Thanks.
> 

I needed clarification on some of the language in the contract, and with
them being so busy that has been taking a while. They've confirmed it's
still in their work queue.

-- 
Kaylee Blake 
C is the worst language, except for all the others.

Re: Clobber REG_CC only for some constraint alternatives?

[Matt Wette via Gcc]

On 8/14/20 4:16 AM, Senthil Kumar Selvaraj via Gcc wrote:

Hi,

   I'm working on porting AVR to MODE_CC, and there are quite a few
   patterns that clobber the condition code reg only for certain
   constraint alternatives. For e.g.,

(define_insn "mov_insn"
   [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d,Qm   ,r 
,q,r,*r")
 (match_operand:ALL1 1 "nox_general_operand"   "r Y00,n Ynn,r 
Y00,Qm,r,q,i"))]
  "register_operand (operands[0], mode)
  || reg_or_0_operand (operands[1], mode)"
  {
   return output_movqi (insn, operands, NULL);
  }
  [(set_attr "length" "1,1,5,5,1,1,4")
  (set_attr "adjust_len" "mov8")
  (set_attr "cc" "ldi,none,clobber,clobber,none,none,clobber")])

As you can deduce from the (set_attr "cc" ..), only constraint
alternatives 0,2,3 and 6 clobber CC - others leave it unchanged.

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. 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?

(define_insn_and_split "mov_insn"
   [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d,Qm   ,r 
,q,r,*r")
 (match_operand:ALL1 1 "nox_general_operand"   "r Y00,n Ynn,r 
Y00,Qm,r,q,i"))]
   "register_operand (operands[0], mode)
 || reg_or_0_operand (operands[1], mode)"
   "#"
   "&& reload_completed"
   [(parallel [(set (match_dup 0)
(match_dup 1))
   (clobber (match_dup 2))])]
   {
 operands[2] = get_cc_reg_clobber_rtx (curr_insn);
   }
   [(set_attr "cc" "ldi,none,clobber,clobber,none,none,clobber")])

(define_insn "*mov_insn_clobber_flags"
   [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,Qm   ,r ,*r")
 (match_operand:ALL1 1 "nox_general_operand"   "r Y00,r Y00,Qm,i"))
(clobber (reg:CC REG_CC))]
   "(register_operand (operands[0], mode)
 || reg_or_0_operand (operands[1], mode))
&& reload_completed"
   {
 return output_movqi (insn, operands, NULL);
   }
   [(set_attr "length" "1,5,5,4")
(set_attr "adjust_len" "mov8")])

(define_insn "*mov_insn_noclobber_flags"
   [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d   ,q,r")
 (match_operand:ALL1 1 "nox_general_operand"   "r,n Ynn,r,q"))
(clobber (const_int 0))]
   "(register_operand (operands[0], mode)
 || reg_or_0_operand (operands[1], mode))
&& reload_completed"
   {
 return output_movqi (insn, operands, NULL);
   }
   [(set_attr "length" "1,1,1,1")
(set_attr "adjust_len" "mov8")])

Regards
Senthil


Happy to see someone working this.   Are you starting with one CC mode?
I noticed that the current CC0 implementation seems to effectively use
several modes.  For example, one for use of the t flag.  I'm sure it 
will be easier

to start with one mode.

Matt

Accessing fields in the global_options structure from out-of-sync plugins

[Nick Clifton via Gcc]

Hi Guys,

  With the annobin plugin for gcc I have a problem accessing some of the
  fields in the global_options structure.  Although the plugin can use
  the macros defined in options.h, this only works if the plugin is in
  sync with gcc.  If the plugin was built for one version of gcc, but
  run from another version, then the access can become invalid if the
  fields in struct gcc_options have changed.  (This does seem to happen
  quite a lot).

  Whilst forcing the plugin to stay in sync with gcc is one possible
  solution, it does have its own problems.  So I am looking for another
  solution.  Using the cl_options array and the flag_var_offset field
  does help.  But cl_options only has entries for some of the fields in
  global_options, not all of them.  (Eg: main_input_filename,
  flag_sanitize, optimize).

  One method that would work would be to enhance the optc-gen.awk and
  opth-gen.awk scripts so that they create a set of accessor functions.
  eg get_main_input_filename() or get_flag_sanitize().  These would not
  have to be used by the current gcc code, but their presence in the
  executable would allow them to be accessed from plugins.
  Alternatively a single accessor function which takes a parameter
  indicating the desired field and which returns its current value would
  also work.

  What do people think ?  Is this idea practical, or is there a better
  solution ?

Cheers
  Nick

Re: Accessing fields in the global_options structure from out-of-sync plugins

[Jakub Jelinek via Gcc]

On Fri, Aug 14, 2020 at 04:33:42PM +0100, Nick Clifton wrote:
>   With the annobin plugin for gcc I have a problem accessing some of the
>   fields in the global_options structure.  Although the plugin can use
>   the macros defined in options.h, this only works if the plugin is in
>   sync with gcc.  If the plugin was built for one version of gcc, but
>   run from another version, then the access can become invalid if the
>   fields in struct gcc_options have changed.  (This does seem to happen
>   quite a lot).
> 
>   Whilst forcing the plugin to stay in sync with gcc is one possible
>   solution, it does have its own problems.  So I am looking for another
>   solution.  Using the cl_options array and the flag_var_offset field
>   does help.  But cl_options only has entries for some of the fields in
>   global_options, not all of them.  (Eg: main_input_filename,
>   flag_sanitize, optimize).
> 
>   One method that would work would be to enhance the optc-gen.awk and
>   opth-gen.awk scripts so that they create a set of accessor functions.
>   eg get_main_input_filename() or get_flag_sanitize().  These would not
>   have to be used by the current gcc code, but their presence in the
>   executable would allow them to be accessed from plugins.
>   Alternatively a single accessor function which takes a parameter
>   indicating the desired field and which returns its current value would
>   also work.
> 
>   What do people think ?  Is this idea practical, or is there a better
>   solution ?

I wrote https://gcc.gnu.org/pipermail/gcc/2020-August/233386.html about this
yesterday.

Jakub

Re: Clobber REG_CC only for some constraint alternatives?

[Segher Boessenkool]

Hi!

On Fri, Aug 14, 2020 at 04:46:59PM +0530, Senthil Kumar Selvaraj via Gcc wrote:
>   I'm working on porting AVR to MODE_CC,

I'm very happy to see people work on that.

> (define_insn "*mov_insn_noclobber_flags"
>   [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d   ,q,r")
> (match_operand:ALL1 1 "nox_general_operand"   "r,n Ynn,r,q"))
>(clobber (const_int 0))]

This is not correct, clobbers like that are not defined RTL, and are
actually used internally (by combine at least), so this will confuse
that.

If you want to say some alternative does not clobber anything, just use
the constraint "X" for that alternative.

$ grep -r "clobber.*scratch.*X" gcc/config/

HtH,


Segher

Peephole optimisation: isWhitespace()

[Stefan Kanthak]

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!
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 % ' ')
 xoredx, edx
 cmpecx, 33   ; CF = c <= ' '
 adcedx, edx  ; edx = (c <= ' ')
 andeax, edx
 ret


regards
Stefan Kanthak

Re: Clobber REG_CC only for some constraint alternatives?

[Pip Cet via Gcc]

On Fri, Aug 14, 2020 at 3:33 PM Matt Wette via Gcc  wrote:
> Happy to see someone working this.   Are you starting with one CC mode?

I'm also working on this (mostly at bug#92792), and so far am using
two modes: the general reg:CC mode for proper comparison insns, and
CCNZ for optimization in the CC-setting variants produced by the
cmpelim pass.

> I noticed that the current CC0 implementation seems to effectively use
> several modes.  For example, one for use of the t flag.

As far as I can tell, the current code emits T setters and getters
together as one insn, even going to the trouble of setting T
redundantly when it already has been set. Am I missing something?

Re: Clobber REG_CC only for some constraint alternatives?

[Pip Cet via Gcc]

On Fri, Aug 14, 2020 at 4:24 PM Segher Boessenkool
 wrote:
> On Fri, Aug 14, 2020 at 04:46:59PM +0530, Senthil Kumar Selvaraj via Gcc 
> wrote:
> > (define_insn "*mov_insn_noclobber_flags"
> >   [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d   ,q,r")
> > (match_operand:ALL1 1 "nox_general_operand"   "r,n Ynn,r,q"))
> >(clobber (const_int 0))]
>
> This is not correct, clobbers like that are not defined RTL, and are
> actually used internally (by combine at least), so this will confuse
> that.
>
> 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?
Because some passes, such as cmpelim, do not currently appear to deal
very well with extra clobbers, so that might be a problem.

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?

Thanks
Pip

how to debug Ada front end

[Martin Sebor via Gcc]

Could someone either point me to directions or explain how to
start the Ada front end in GDB?  I've searched the GCC Wiki
but couldn't find anything useful and no matter what I do I get
errors, either:

fatal error, run-time library not installed correctly
cannot locate file system.ads
compilation abandoned

When I do manage to set LD_LIBRARY_PATH to what I see it set
in gcc/testsuite/gnat/gnat.log and compile a program, trying
to invoke GDB on the front end fails with another error.

Thanks
Martin

Here's my invocation:
LD_LIBRARY_PATH=$BUILDROOT/gcc:$BUILDROOT/gcc/32::$BUILDROOT/gcc:$BUILDROOT/gcc/32:$BUILDROOT/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libsanitizer/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libvtv/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libssp/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libphobos/src/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libgomp/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libitm/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libatomic/.libs:$BUILDROOT/./gcc:$BUILDROOT/./prev-gcc:$BUILDROOT/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libsanitizer/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libvtv/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libssp/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libphobos/src/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libgomp/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libitm/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libatomic/.libs:$BUILDROOT/./gcc:$BUILDROOT/./prev-gcc 
$BUILDROOT/gcc/gnatmake --GCC=$BUILDROOT/gcc/xgcc 
--GNATBIND=$BUILDROOT/gcc/gnatbind --GNATLINK=$BUILDROOT/gcc/gnatlink 
-cargs -B$BUILDROOT/gcc -largs --GCC=$BUILDROOT/gcc/xgcc 
-B$BUILDROOT/gcc  -margs --RTS=$BUILDROOT/x86_64-pc-linux-gnu/./libada 
-q -f $SRCROOT/gcc/testsuite/gnat.dg/array21.adb -c -v 
-fdiagnostics-plain-output


GNATMAKE 11.0.0 20200814 (experimental)
Copyright (C) 1992-2020, Free Software Foundation, Inc.
xgcc: fatal error: cannot execute ‘-I-’: execvp: No such file or directory
compilation terminated.
End of compilation
gnatmake: "/build/gcc/gcc/testsuite/gnat.dg/array21.adb" compilation error

Re: how to debug Ada front end

[Martin Sebor via Gcc]

I've got it.  Just removing all the gnatmake cruft and options
the GCC driver doesn't understand and invoking GCC as usual
works.  Phew.  It would be useful to update the GNAT Wiki with
this.  I'll probably get most of it wrong but let me give it
a try.

On 8/14/20 3:53 PM, Martin Sebor wrote:

Could someone either point me to directions or explain how to
start the Ada front end in GDB?  I've searched the GCC Wiki
but couldn't find anything useful and no matter what I do I get
errors, either:

fatal error, run-time library not installed correctly
cannot locate file system.ads
compilation abandoned

When I do manage to set LD_LIBRARY_PATH to what I see it set
in gcc/testsuite/gnat/gnat.log and compile a program, trying
to invoke GDB on the front end fails with another error.

Thanks
Martin

Here's my invocation:
LD_LIBRARY_PATH=$BUILDROOT/gcc:$BUILDROOT/gcc/32::$BUILDROOT/gcc:$BUILDROOT/gcc/32:$BUILDROOT/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libsanitizer/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libvtv/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libssp/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libphobos/src/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libgomp/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libitm/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libatomic/.libs:$BUILDROOT/./gcc:$BUILDROOT/./prev-gcc:$BUILDROOT/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libsanitizer/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libvtv/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libssp/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libphobos/src/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libgomp/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libitm/.libs:$BUILDROOT/x86_64-pc-linux-gnu/libatomic/.libs:$BUILDROOT/./gcc:$BUILDROOT/./prev-gcc 
$BUILDROOT/gcc/gnatmake --GCC=$BUILDROOT/gcc/xgcc 
--GNATBIND=$BUILDROOT/gcc/gnatbind --GNATLINK=$BUILDROOT/gcc/gnatlink 
-cargs -B$BUILDROOT/gcc -largs --GCC=$BUILDROOT/gcc/xgcc 
-B$BUILDROOT/gcc  -margs --RTS=$BUILDROOT/x86_64-pc-linux-gnu/./libada 
-q -f $SRCROOT/gcc/testsuite/gnat.dg/array21.adb -c -v 
-fdiagnostics-plain-output


GNATMAKE 11.0.0 20200814 (experimental)
Copyright (C) 1992-2020, Free Software Foundation, Inc.
xgcc: fatal error: cannot execute ‘-I-’: execvp: No such file or directory
compilation terminated.
End of compilation
gnatmake: "/build/gcc/gcc/testsuite/gnat.dg/array21.adb" compilation error

gcc-9-20200814 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-9-20200814.tar.xzComplete GCC

  SHA256=96a732f1f375f50c7b5419fbaab7199728f3eb009914d33ee1328e21e384e777
  SHA1=4d8cad0511b5c322f09e4a4796ee573a640ce5b9

Diffs from 9-20200807 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
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]

Hi!

On Fri, Aug 14, 2020 at 05:47:02PM +, Pip Cet wrote:
> On Fri, Aug 14, 2020 at 4:24 PM Segher Boessenkool
>  wrote:
> > On Fri, Aug 14, 2020 at 04:46:59PM +0530, Senthil Kumar Selvaraj via Gcc 
> > wrote:
> > > (define_insn "*mov_insn_noclobber_flags"
> > >   [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d   ,q,r")
> > > (match_operand:ALL1 1 "nox_general_operand"   "r,n Ynn,r,q"))
> > >(clobber (const_int 0))]
> >
> > This is not correct, clobbers like that are not defined RTL, and are
> > actually used internally (by combine at least), so this will confuse
> > that.
> >
> > 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.

> Because some passes, such as cmpelim, do not currently appear to deal
> very well with extra clobbers, so that might be a problem.

Not sure if it would mind here...  It is not a clobber of a reg.

> 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.


Segher