Hi Vladimir,
On 2023/11/17 22:05, Vladimir Makarov wrote:
On 11/16/23 21:06, Lehua Ding wrote:
Hi Vladimir,
Thank you so much for your review. Based on your comments, I feel like
there are a lot of issues, especially the long compile time issue. So
I'm going to reorganize and refactor the p
Lehua Ding writes:
> Hi Vladimir,
>
> On 2023/11/17 22:05, Vladimir Makarov wrote:
>> On 11/16/23 21:06, Lehua Ding wrote:
>>> Hi Vladimir,
>>>
>>> Thank you so much for your review. Based on your comments, I feel
>>> like there are a lot of issues, especially the long compile time
>>> issue. S
I have no problem, thanks for fixing the bug
在 2023/11/18 上午4:43, Xi Ruoyao 写道:
Superseds
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636795.html.
Requires
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636946.html.
Changes:
- Rebase on top of "Add LoongarchV1.1 instructi
Pushed to r14-5568.
在 2023/11/17 下午7:09, Xi Ruoyao 写道:
On Fri, 2023-11-17 at 16:33 +0800, Lulu Cheng wrote:
Lulu Cheng (3):
LoongArch: Add LA664 support.
LoongArch: Implement atomic operations using LoongArch1.1
instructions.
LoongArch: atomic_load and atomic_store are implemented
Pushed to r14-5567.
在 2023/11/16 下午3:27, Lulu Cheng 写道:
When compiling with '-mcmodel=medium', the function call is made through
'pcaddu18i+jirl' if binutils supports call36, otherwise the
native implementation 'pcalau12i+jirl' is used.
gcc/ChangeLog:
* config.in: Regenerate.
*
Hi Sam,
On 2023/11/18 16:06, Sam James wrote:
Lehua Ding writes:
Hi Vladimir,
On 2023/11/17 22:05, Vladimir Makarov wrote:
On 11/16/23 21:06, Lehua Ding wrote:
Hi Vladimir,
Thank you so much for your review. Based on your comments, I feel
like there are a lot of issues, especially the lo
Lehua Ding writes:
> Hi Sam,
>
> On 2023/11/18 16:06, Sam James wrote:
>> Lehua Ding writes:
>>
>>> Hi Vladimir,
>>>
>>> On 2023/11/17 22:05, Vladimir Makarov wrote:
On 11/16/23 21:06, Lehua Ding wrote:
> Hi Vladimir,
>
> Thank you so much for your review. Based on your comme
On 2023/11/18 16:24, Sam James wrote:
Lehua Ding writes:
Hi Sam,
On 2023/11/18 16:06, Sam James wrote:
Lehua Ding writes:
Hi Vladimir,
On 2023/11/17 22:05, Vladimir Makarov wrote:
On 11/16/23 21:06, Lehua Ding wrote:
Hi Vladimir,
Thank you so much for your review. Based on your co
Hello All:
Loop invariant code motion can increase register pressure if the
live ranges increases and there could be spill happening.
In tree-ssa representaion, we have the proof tha livein at
the loop header will be live-in across all the basic blocks
inside the loop.
We want to evaluate that h
Hi,
Libstdc++ patches need to be CC'd to the gcc-patches list as well.
On Wed, 8 Nov 2023 at 10:26, Peng Fan wrote:
>
> libstdc++-v3:
>
> * configure.host: Add abi_baseline_pair for LoongArch.
> * config/abi/post/riscv64-linux-gnu: New directory.
> * config/abi/post/riscv64-linux-gnu
On Sat, 2023-11-18 at 08:43 +, Jonathan Wakely wrote:
> Hi,
>
> Libstdc++ patches need to be CC'd to the gcc-patches list as well.
>
> On Wed, 8 Nov 2023 at 10:26, Peng Fan wrote:
> >
> > libstdc++-v3:
> >
> > * configure.host: Add abi_baseline_pair for LoongArch.
> > * config/abi/
> I suppose 'set t [...]' can be let go, too?
Duh (x2).
Pushed, on top of the previous patch.
FX
0001-Testsuite-remove-unused-variables.patch
Description: Binary data
On Sat, 2023-11-18 at 14:59 +0800, Guo Jie wrote:
> For the following immediate load operation in
> gcc/testsuite/gcc.target/loongarch/imm-load1.c:
>
> long long r = 0x0101010101010101;
>
> Before this patch:
>
> lu12i.w $r15,16842752>>12
> ori $r15,$r15,257
>
On Fri, Nov 17, 2023 at 12:40 PM juzhe.zh...@rivai.ai
wrote:
>
> 90% theadvector extension reusing current RVV 1.0 instructions patterns:
> Just change ASM, For example:
>
> @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh_scalar"
> (match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr"
On Fri, 17 Nov 2023 at 22:47, Jeff Law wrote:
>
>
>
> On 11/17/23 04:39, juzhe.zh...@rivai.ai wrote:
> > 90% theadvector extension reusing current RVV 1.0 instructions patterns:
> > Just change ASM, For example:
> >
> > @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh_scalar"
> >(match_o
> On 11/17/23 07:18, Kito Cheng wrote:
> > I didn’t take a closer look yet on the ira/lra dump yet, but my feeling
> > is that may cause by the earlyclober modifier isn’t work as expect?
> >
> > Let me take closer look tomorrow.
> Remember that constraints aren't checked until register allocation.
LGTM, and could you add one more comment before that condition: /*
Non-fractional LMUL has whole register moves that don't require a
vsetvl for VLMAX. */
On Fri, Nov 17, 2023 at 9:48 PM Juzhe-Zhong wrote:
>
> Fix segment fault on tuple move:
>
> bbl loader
> z ra 000102
On Sat, Nov 18, 2023 at 12:27 PM Jun Sha (Joshua)
wrote:
>
> This patch is to introduce basic XTheadVector support
> (march string parsing and a test for __riscv_xtheadvector)
> according to https://github.com/T-head-Semi/thead-extension-spec/
>
> Contributors:
> Jun Sha (Joshua)
>
> diff --git a/gcc/config/riscv/riscv_th_vector.h
> b/gcc/config/riscv/riscv_th_vector.h
> new file mode 100644
> index 000..194652032bc
> --- /dev/null
> +++ b/gcc/config/riscv/riscv_th_vector.h
...
> +/* NOTE: This implementation of riscv_vector.h is intentionally short. It
> does
> +
Hi!
On Fri, Nov 17, 2023 at 03:01:04PM +0100, Jakub Jelinek wrote:
> As a follow-up, I'm considering changing in this routine the popcount
> call to IFN_POPCOUNT with 2 arguments and during expansion test costs.
Here is the follow-up which does the rtx costs testing.
While having to tweak interna
I guess it would be worth to state my thought publicly:
I *support* adding the T-head vector (a.k.a. vector 0.7) to upstream
GCC since T-Head vector already ships a large enough number of boards,
also it's not really T-head's problem as Palmer described in another
mail.
My biggest concern before
gcc/ChangeLog:
* config/riscv/riscv-target-attr.cc
(riscv_target_attr_parser::parse_arch): Use char[] for
std::unique_ptr to prevent mismatched new delete issue.
(riscv_process_one_target_attr): Ditto.
(riscv_process_target_attr): Ditto.
---
gcc/config/risc
Fixed on upstream, thanks for reporting, I guess my host GCC is just
too old. It doesn't even not report that bug with -Wall -Wextra..
On Fri, Nov 17, 2023 at 11:41 PM Andreas Schwab wrote:
>
> In file included from
> /daten/riscv64/gcc/gcc-20231117/Build/prev-riscv64-suse-linux/libstdc++-v3/inc
Actually, disregard this patch. I'm preparing a better one which also
tackles UB in
month - months{INT_MIN}
weekday - days{INT_MIN}
Best wishes,
Cassio.
On Sat, 18 Nov 2023, 00:19 Cassio Neri, wrote:
> The following functions invoke signed integer overflow (UB) for some
> extreme
> values of d
Currently I start to work on full coverage testing (with different compile
option test GCC testsuite)
and fix bugs which is highest priority definitely.
I am not able to find the time review this patch on GCC-14 for now.
So conservatively, postpone it to GCC-15.
If we are lucky that I stabliz
Verify, for short forward branch, T-Head, Ventana and Zicond targets and
the ordered floating-point conditional-move operations that already work
as expected, that if-conversion triggers via `noce_try_cmove' at the
respective sufficiently high `-mbranch-cost=' settings that make
branchless code
On Sat, 2023-11-18 at 16:16 +0800, chenglulu wrote:
> Pushed to r14-5567.
>
> 在 2023/11/16 下午3:27, Lulu Cheng 写道:
> > When compiling with '-mcmodel=medium', the function call is made through
> > 'pcaddu18i+jirl' if binutils supports call36, otherwise the
> > native implementation 'pcalau12i+jirl'
Even if !HAVE_AS_SUPPORT_CALL36, const_call_insn_operand should still
return false when -mexplict-relocs=none -mcmodel=medium to make
loongarch_legitimize_call_address emit la.local or la.global.
gcc/ChangeLog:
* config/loongarch/predicates.md (const_call_insn_operand):
Remove bug
On 11/18/23 09:50, Maciej W. Rozycki wrote:
Verify, for short forward branch, T-Head, Ventana and Zicond targets and
the ordered floating-point conditional-move operations that already work
as expected, that if-conversion triggers via `noce_try_cmove' at the
respective sufficiently high `-mbra
On Fri, 2023-11-17 at 10:21 +0800, chenglulu wrote:
> Pushed to r14-5545.
>
> 在 2023/11/16 下午4:44, Jiahao Xu 写道:
> > Based on SPEC2017 performance evaluation results, it's better to make them
> > equal
> > to the cost of unaligned store/load so as to avoid odd alignment peeling.
> >
> > gcc/Chan
David Edelsohn writes:
> On Fri, Nov 17, 2023 at 10:17 AM Arsen Arsenović wrote:
>
>>
>> David Edelsohn writes:
>>
>> > On Fri, Nov 17, 2023 at 3:46 AM Arsen Arsenović wrote:
>> >
>> >>
>> >> David Edelsohn writes:
>> >>
>> >> > On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović
>> wrote:
>> >
Hi!
In https://sourceware.org/pipermail/libc-alpha/2023-November/152819.html
Florian Weimer raised concern that the type-generic stdbit.h macros
currently being considered suffer from similar problem as old tgmath.h
implementation, in particular that the macros expand during preprocessing
their ar
Hi!
Another obstackle mentioned in the
https://sourceware.org/pipermail/libc-alpha/2023-November/152819.html
thread is that half of the stdc_{leading,trailing}_{zeros,ones},
stdc_first_{leading,trailing}_{zero,one} and stdc_count_{zeros,ones}
type-generic macros actually need to use the __builtin_
Hi!
For these 3 type-generic macros I'm out of ideas how to satisfy
all the requirements (no use of ({ ... }), not expanding argument multiple
times, not evaluating side-effects multiple times using some small building
blocks, so the following patch introduces 3 new C only builtins which
can be us
libstdc++-v3/ChangeLog:
* include/Makefile.am: Install std/generator, bits/elements_of.h
as freestanding.
* include/Makefile.in: Regenerate.
* include/bits/version.def: Add __cpp_lib_generator.
* include/bits/version.h: Regenerate.
* include/precompi
This is another revised series for checking for
bounds consistency when assigning VM types.
Based on feedback, I disentangled this from UBSan for
a three reasons:
- I think it makes sense as a stand-alone feature
similar to other run-time instrumentation features
GCC already has.
- Not all c
When checking compatibility of types during assignment, collect
all pairs of types where the outermost bound needs to match at
run-time. This list is then processed to add runtime checks for
each bound.
gcc/c-family:
* c-opt (fvla-bounds): New flag.
gcc/c:
* c-typeck.cc (struc
Support instrumentation of function arguments for functions
called via a declaration. We can support only simple size
expressions without side effects, because the run-time
instrumentation is done before the call, but the expressions
are evaluated in the callee.
gcc/c:
* c-typeck.cc (p
Support instrumentation of functions called via pointers. To do so,
record the declaration with the parameter types, so that it can be
retrieved later.
gcc/c:
c-decl.cc (get_parm_info): Record function declaration
for arguments.
c-typeck.cc (process_vm_constraints): Ins
Add warning for the case when a function call can not be instrumened.
gcc/c-family/:
* c.opt (Wvla-parameter-missing-check): Add warning.
gcc/c/:
* c-typeck.cc (process_vm_constraints): Add warning.
gcc/doc/:
* invoke.texi (Wvla-parameter-missing-check): Document warni
This patch adds support for hardware loops as described in:
https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/cv32e40p_v1.3.2/instruction_set_extensions.html#hardware-loops
.
riscv32-corev-elf (using newlib) regression tested for multilibs:
rv32imc_zicsr-ilp32--
rv32imfc_zicsr-ilp32--
Here's an improved version of this patch, which I've pushed to trunk.
Testeed x86_64-linux.
-- >8 --
This optimizes the simple case of formatting a single string, integer
or bool, with no format-specifier (so no padding, alignment, alternate
form etc.)
libstdc++-v3/ChangeLog:
PR libstd
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 needed too.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/112607
* include/std/format (basic_format_arg::_S_to_arg_type): Check
value_type for basic_string_view and basic_string
specializations.
* te
Hi all,
Fortran 2023 added restrictions on integer arguments to SYSTEM_CLOCK.
The attached patch implements these.
I was struggling with the way we should handle features that are sort-of
deleted in a new standard, but not described as such in the standard,
which is why we do not have GFC_STD_F20
On 11/17/23 15:19, Lewis Hyatt wrote:
Hello-
I often find it convenient to run a new c-c++-common test from the
main build dir like:
$ make -j 2 RUNTESTFLAGS=dg.exp=new-test.c check-gcc-{c,c++}
I noticed that sometimes this produces a corrupted site.exp and then no
tests work until it is re
On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote:
>
> Fortran 2023 added restrictions on integer arguments to SYSTEM_CLOCK.
> The attached patch implements these.
>
> I was struggling with the way we should handle features that are sort-of
> deleted in a new standard, but not describ
Hi,
this patch implements very basic propaation of return value ranges from VRP
pass. This helps std::vector's push_back since we work out value range of
allocated block. This propagates only within single translation unit. I hoped
we will also do the propagation at WPA stage, but that needs mor
This patch:
- adds support to the analyzer for tracking API-private state
or which we don't have a decl (such as strtok's internal state),
- uses it to implement a new -Wanalyzer-undefined-behavior-strtok which
warns when strtok (NULL, delim) is called as the first call to
strtok after main.
PR target/112561
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_tuple_move): Fix bug.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr112561.c: New test.
---
gcc/config/riscv/riscv-v.cc | 4
.../gcc.target/riscv/rvv/autovec/pr11
On 11/17/23 07:01, Jakub Jelinek wrote:
Hi!
Per the earlier discussions on this PR, the following patch folds
popcount (x) == 1 (and != 1) into (x ^ (x - 1)) > x - 1 (or <=)
if the corresponding popcount optab isn't implemented (I think any
double-word popcount or call will be necessarily slo
On 11/18/23 03:27, Jakub Jelinek wrote:
Hi!
On Fri, Nov 17, 2023 at 03:01:04PM +0100, Jakub Jelinek wrote:
As a follow-up, I'm considering changing in this routine the popcount
call to IFN_POPCOUNT with 2 arguments and during expansion test costs.
Here is the follow-up which does the rtx c
On 11/10/23 11:00, Patrick O'Neill wrote:
On 11/9/23 17:34, Jeff Law wrote:
On 11/3/23 00:18, Patrick O'Neill wrote:
On non-vector targets dejagnu attempts dg-do compile for pr95401.cc.
This produces a command like this:
g++ pr95401.cc pr95401a.cc -S -o pr95401.s
which isn't valid (gcc d
On 11/15/23 17:03, Patrick O'Neill wrote:
Ping.
Testsuite fixup similar to:
https://inbox.sourceware.org/gcc-patches/974e9e5e-8f07-46dd-b9b9-db8aa4685...@gmail.com/T/#t
https://inbox.sourceware.org/gcc-patches/7e78cd70-70c9-41b1-8a98-6977a1034...@rivosinc.com/T/#t
OK.
Jeff
Hi,
This patch series has come out from a simple change to add generic
conditional-move and conditional-add expansions for a yet-out-of-tree
target, which has relatively expensive branches and no conditional
operations beyond the base architecture conditional-set instructions. At
one point I
Add generic execution tests for expressions that are expected to expand
to conditional-move and conditional-add operations where supported. To
ensure no corner case escapes all relational operators are extensively
covered for integer comparisons and all ordered operators are covered
for floati
Verify, for short forward branch targets and the conditional-move
operations that already work as expected, that if-conversion triggers
via `noce_try_cmove' already at `-mbranch-cost=1' and that extraneous
instructions such as SNEZ, etc. are not present in output. Cover all
integer relational
Our `movcc' expander is no longer specific to short forward branch
targets, so move its associated comment accordingly.
gcc/
* config/riscv/riscv.md (movcc): Move comment on SFB
patterns over to...
(*movcc): ... here.
---
gcc/config/riscv/riscv.md |4 ++--
1
For the NEED_EQ_NE_P `riscv_emit_int_compare' is documented to only emit
EQ or NE comparisons against zero, however it does not catch incorrect
use where a non-equality comparison has been requested and falls through
to the general case then. Add a safety guard to catch such a case then.
Argua
In `riscv_expand_conditional_move' `mode' is initialized right away from
`GET_MODE (dest)', so remove needless references that refrain from using
the local variable.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Use
`mode' for `GET_MODE (dest)' throughout
Use `mode0' and `mode1' shorthands respectively for `GET_MODE (op0)' and
`GET_MODE (op1)' to improve code readability.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Use
`mode0' and `mode1' for `GET_MODE (op0)' and `GET_MODE (op1)'.
---
gcc/config/riscv/ri
Just choose between EQ and NE at `gen_rtx_fmt_ee' invocation, removing
an extraneous variable only referred once and improving code clarity.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Remove
extraneous variable for EQ vs NE operation selection.
---
FWIW
Use `nullptr' for consistency rather than 0 to initialize `invert_ptr'.
gcc/
* config/riscv/riscv.cc (riscv_expand_conditional_move): Use
`nullptr' rather than 0 to initialize a pointer.
---
gcc/config/riscv/riscv.cc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-
The generic branch costing model for if-conversion assumes a fixed cost
of COSTS_N_INSNS (2) for a conditional branch, and that one half of that
cost comes from a preceding condition-set instruction, such as with
MODE_CC targets, and then the other half of that cost is for the actual
branch ins
Verify, for T-Head, Ventana and Zicond targets and the integer
conditional-move operations that already work as expected, that
if-conversion does *not* trigger at the respective sufficiently low
`-mbranch-cost=' settings that make original branched code sequences
cheaper than their branchless e
Verify, for T-Head, Ventana and Zicond targets and the integer
conditional-move operations that already work as expected, if-conversion
to trigger via `noce_try_cmove' at the respective sufficiently high
`-mbranch-cost=' settings that make branchless code sequences produced
by if-conversion che
Verify, for Ventana and Zicond targets and the ordered floating-point
conditional-move operations that already work as expected, that
if-conversion does *not* trigger at `-mbranch-cost=2' setting, which
makes original branched code sequences cheaper than their branchless
equivalents if-conversi
Verify, for Ventana and Zicond targets and the GEU and LEU
conditional-move operations, that if-conversion triggers via
`noce_try_cmove' at `-mbranch-cost=4' setting, which makes branchless
code sequences produced by if-conversion cheaper than their original
branched equivalents, and that extra
In the non-zero case there is no need for the conditional value used by
Ventana and Zicond integer conditional operations to be specifically 1.
Regardless we canonicalize it by producing an extraneous conditional-set
operation, such as with the sequence below:
(insn 22 6 23 2 (set (reg:DI 141)
Update `riscv_expand_conditional_move' and handle the missing GEU and
LEU operators there, avoiding an extraneous conditional set operation,
such as with this output:
sgtua0,a0,a1
seqza1,a0
czero.eqz a3,a3,a1
czero.nez a1,a2,a1
or
Verify, for Ventana and Zicond targets and the equality conditional-move
operations, that if-conversion does *not* trigger at the respective
sufficiently low `-mbranch-cost=' settings that make original branched
code sequences cheaper than their branchless equivalents if-conversion
would emit.
Verify, for Ventana and Zicond targets and the equality conditional-move
operations, that if-conversion triggers via `noce_try_cmove' at the
respective sufficiently high `-mbranch-cost=' settings that make
branchless code sequences produced by if-conversion cheaper than their
original branched
Verify, for Ventana and Zicond targets and the GEU and LEU
conditional-move operations, that if-conversion does *not* trigger at
`-mbranch-cost=3' setting, which makes original branched code sequences
cheaper than their branchless equivalents if-conversion would emit.
gcc/testsuite/
There is no need for the requirement for conditional-move comparison
operands to be stricter for T-Head targets than for other targets and
limit them to registers only. Constants will be reloaded if required
just as with branches or other-target conditional-move operations and
there is no extr
There is no need for the requirement for conditional-move data input
operands to be stricter for T-Head targets than for short forward branch
targets and limit them to registers only. They are keyed according to
the `sfb_alu_operand' predicate, which lets certain constants through.
Such const
Code in `riscv_expand_conditional_move' for Ventana and Zicond targets
seems like bolted on as an afterthought rather than properly merged so
as to handle all the cases together.
Fold the existing code pieces together then (observing that for short
forward branch targets no integer comparisons
Verify, for T-Head targets and the non-equality integer conditional-move
operations, that if-conversion does *not* trigger at `-mbranch-cost=1'
setting, which makes original branched code sequences cheaper than their
branchless equivalents if-conversion would emit.
gcc/testsuite/
Add a `riscv_emit_unary' helper for unary operations, complementing
`riscv_emit_binary'.
gcc/
* config/riscv/riscv-protos.h (riscv_emit_unary): New prototype.
* config/riscv/riscv.cc (riscv_emit_unary): New function.
---
gcc/config/riscv/riscv-protos.h |1 +
gcc/confi
Verify, for T-Head targets and the non-equality integer conditional-move
operations, that if-conversion triggers via `noce_try_cmove' at
`-mbranch-cost=2' setting, which makes branchless code sequences
produced by if-conversion cheaper than their original branched
equivalents, and that extraneo
Provide RTL expansion of conditional-move operations for generic targets
using a suitable sequence of base integer machine instructions according
to cost evaluation by if-conversion. Add `-mmovcc' command line option
to enable this transformation, off by default.
For the generic sequences smal
Verify, for generic integer conditional-move operations, if-conversion
to trigger via `noce_try_cmove' at the respective sufficiently high
`-mbranch-cost=' settings that make branchless code sequences produced
by if-conversion cheaper than their original branched equivalents, and,
where applica
Verify, for generic integer conditional-add operations, if-conversion
*not* to trigger at the respective sufficiently low `-mbranch-cost='
settings that make original branched code sequences cheaper than their
branchless equivalents if-conversion would emit. Cover all integer
relational operat
Verify, for generic integer conditional-move operations, if-conversion
*not* to trigger at the respective sufficiently low `-mbranch-cost='
settings that make original branched code sequences cheaper than their
branchless equivalents if-conversion would emit. Cover all integer
relational opera
Verify, for generic integer conditional-add operations, if-conversion
to trigger via `noce_try_addcc' at the respective sufficiently high
`-mbranch-cost=' settings that make branchless code sequences produced
by if-conversion cheaper than their original branched equivalents, and,
where applicable,
In `riscv_expand_conditional_move' we only let integer conditions
through at the moment, even though code has already been prepared to
handle floating-point conditions as well.
Lift this restriction and only bail out if a non-word-mode integer
condition has been requested, as we cannot handle t
Provide RTL expansion of conditional-add operations for generic targets
using a suitable sequence of base integer machine instructions according
to cost evaluation by if-conversion. Use existing `-mmovcc' command
line option to enable this transformation.
gcc/
* config/riscv/ri
Do not expand floating-point conditional-branch RTL instructions right
away that use a comparison operation that is either directly available
as a machine conditional-set instruction or is NE, which can be emulated
by EQ. This is so that if-conversion sees them in their original form
and can p
Verify, for generic floating-point conditional-move operations that have
a corresponding conditional-set machine instruction, that if-conversion
triggers (via `cond_move_convert_if_block', which doesn't report) at
`-mbranch-cost=5' setting, which makes branchless code sequences emitted
by if-co
A subsequent change to enable the processing of conditional moves on a
floating-point condition by `riscv_expand_conditional_move' will cause
`riscv_expand_float_scc' to be called for word-mode target RTX with RV64
targets. In that case an invalid insn such as:
(insn 25 24 0 (set (reg:DI 141)
We have floating-point coditional-set machine instructions for a subset
of FP comparisons, so avoid going through a comparison against constant
zero in `riscv_expand_float_scc' where not necessary, preventing an
extraneous RTL instruction from being produced that counts against the
cost of the
Verify, for generic floating-point conditional-add operations that have
a corresponding conditional-set machine instruction, that if-conversion
does *not* trigger at `-mbranch-cost=2' setting, which makes original
branched code sequences cheaper than their branchless equivalents
if-conversion w
Verify, for generic floating-point conditional-move operations that have
a corresponding conditional-set machine instruction, that if-conversion
does *not* trigger at `-mbranch-cost=4' setting, which makes original
branched code sequences cheaper than their branchless equivalents
if-conversion
We have no FNE.fmt machine instructions, but we can emulate them for the
purpose of conditional-move and conditional-add operations by using the
respective FEQ.fmt instruction and then swapping the data input operands
or complementing the mask for the conditional addend respectively, so
update
Verify, for generic floating-point conditional-add operations that have
a corresponding conditional-set machine instruction, that if-conversion
triggers via `noce_try_addcc' at `-mbranch-cost=3' setting, which makes
branchless code sequences emitted by if-conversion cheaper than their
original
Verify, for generic, Ventana and Zicond targets and the floating-point
NE conditional-move operation, that if-conversion does *not* trigger at
the respective sufficiently low `-mbranch-cost=' settings that make
original branched code sequences cheaper than their branchless
equivalents if-conver
Verify, for the floating-point NE conditional-move operation, that
if-conversion triggers via `noce_try_cmove' at the respective
sufficiently high `-mbranch-cost=' settings that make branchless code
sequences produced by if-conversion cheaper than their original branched
equivalents, and that e
Verify, for the generic floating-point NE conditional-add operation,
that if-conversion does *not* trigger at `-mbranch-cost=2' setting,
which makes original branched code sequences cheaper than their
branchless equivalents if-conversion would emit.
gcc/testsuite/
* gcc.target/r
Verify, for the generic floating-point NE conditional-add operation,
that if-conversion triggers via `noce_try_addcc' at `-mbranch-cost=3'
setting, which makes branchless code sequences emitted by if-conversion
cheaper than their original branched equivalents, and that extraneous
instructions s
quick response for this patch set, it's a really huge number of
patches, so I'll review it individually, and feel free to commit
individual one once got LGTM for each single patch :P
On Sun, Nov 19, 2023 at 1:35 PM Maciej W. Rozycki wrote:
>
> Hi,
>
> This patch series has come out from a simpl
ok
On Sun, Nov 19, 2023 at 1:35 PM Maciej W. Rozycki wrote:
>
> Add generic execution tests for expressions that are expected to expand
> to conditional-move and conditional-add operations where supported. To
> ensure no corner case escapes all relational operators are extensively
> covered for
LGTM
On Sun, Nov 19, 2023 at 1:37 PM Maciej W. Rozycki wrote:
>
> Use `nullptr' for consistency rather than 0 to initialize `invert_ptr'.
>
> gcc/
> * config/riscv/riscv.cc (riscv_expand_conditional_move): Use
> `nullptr' rather than 0 to initialize a pointer.
> ---
> gcc
1 - 100 of 121 matches
Mail list logo
