Re: Clobber REG_CC only for some constraint alternatives?
On Sun, 16 Aug 2020, Pip Cet via Gcc wrote: > For example, here's what I currently have: > > (define_expand "mov" > [(parallel [(set (match_operand:MOVMODE 0 "nonimmediate_operand" "") >(match_operand:MOVMODE 1 "general_operand" "")) > (clobber (reg:CC REG_CC))])] > ...) > > (define_insn "mov_insn" >[(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,r ,d,Qm > ,r ,q,r,*r") > (match_operand:ALL1 1 "nox_general_operand" "r,Y00,n Ynn,r > Y00,Qm,r,q,i")) >(clobber (match_scratch:CC 2 "=X,c,X,c,c,X,X,c"))] > ...) > > That works, but it results in an incorrect CC clobber for, say, > register-to-register movqi. For that, I'd need something like Another way to re-use an existing "cc" attribute from cc0 times is like I did in a82c9fb3f70 (supporting machinery and movsi usage), minimizing code edits and duplication when using it for CC-setting insns. For an example of that, see the subsequent commit a33649e6664. (Just decorate the insn name with the appropriate define_subst ornament!) I'll be quiet now, but good luck. brgds, H-P
Release of GNU MPC 1.2.0
We are very pleased to announce the release of version 1.2.0 "Hyacinthus orientalis" of GNU MPC, a C library for the arithmetic of complex numbers with arbitrarily high precision and correct rounding of the result, available from https://ftp.gnu.org/pub/gnu/mpc/ The release features the new functions mpc_sum and mpc_dot and several bug fixes, in particular to make functions more robust if the user reduces the exponent range. It also contains the tool mpcheck for easier comparison with computations by the C library on standard precision floating-point numbers. The library requires the presence of the recently released version 4.1.0 of GNU MPFR, and it is recommended to compile both with the most recent version 6.2.0 of GMP. We thank Jeffrey Walton, Dennis Clarke, Dagobert Michelsen and Rob "sisyphus" for extensive testing of the release candidate. Enjoy, Paul Zimmermann and Andreas Enge
kernel+toolchain tracks at plumbers
Hi All,
Between the GNU toolchain track, GNU toolchain MC, LLVM BoF, and LLVM
MC at Plumbers 2020, we may be getting close to having more toolchain
topics than kernel topics at plumbers this year. :^D
https://linuxplumbersconf.org/event/7/timetable/?view=lpc
I'll be spending time between the above 4 for most of the conference.
I wanted to share the word on some of the talks we had lined up that
would be useful to have folks from a bunch of different tooling
backgrounds to help inform the discussion. In particular:
Dependency Ordering in the Linux kernel
https://linuxplumbersconf.org/event/7/contributions/821/
which should have feedback on the Linux kernel's memory model for implementers.
and
asm goto w/ outputs
https://linuxplumbersconf.org/event/7/contributions/801/
which would be useful to help discuss collaboration on designs of
future language extension in the context of the Linux kernel.
I'm particularly interested in
https://linuxplumbersconf.org/event/7/contributions/771/ ("Exploring
Profile Guided Optimization of the Linux Kernel") and the BoF
https://linuxplumbersconf.org/event/7/contributions/726/. If there's
other topics that would be particularly helpful to have LLVM folks in
the room, please let me know and I'll help promote it.
See you at the show!
--
Thanks,
~Nick Desaulniers
Re: Clobber REG_CC only for some constraint alternatives?
Hans-Peter Nilsson writes: > 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. This sounds like a great plan - the idea of always generating insn variants for however many CCmodes are available, and then using cc_enabled to disable them selectively (based on the attribute value corresponding to the alternative chosen) looks really neat. I did not understand the purpose of subst_attr for "ccnz" "ccnzvc" and "" though - wouldn't a (set_attr "cc_enabled", "...") do the same thing? Also, I already have a version that hides REG_CC until reload (based on the suggestion in the wiki page), but I guess this approach will work equally well with that too? Regards Senthil
