On 10/19/23 13:46, Richard Sandiford wrote:
+ /* Allow a wide range of operations and let the costing function decide
+if the conversion is worth it later. */
+ enum rtx_code code = GET_CODE (src);
+ if (!(CONSTANT_P (src)
+ || code == REG
+ || code
On 8/30/23 04:14, Manolis Tsamis wrote:
This code used to handle register replacement issues with SUBREG before
simplify_replace_rtx was introduced. This should not be needed anymore as
new_val has the correct mode and that should be preserved by
simplify_replace_rtx.
gcc/ChangeLog:
On 8/30/23 04:13, Manolis Tsamis wrote:
The existing implementation of need_cmov_or_rewire and
noce_convert_multiple_sets_1 assumes that sets are either REG or SUBREG.
This commit enchances them so they can handle/rewire arbitrary set statements.
To do that a new helper struct noce_multiple_s
On 8/28/23 23:25, Mao via Gcc-patches wrote:
The -fpatchable-function-entry is missing in both the web doc [1]
and the man page's "Option Summary" section.
This patch is to add it.
[1]: https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
THanks. I created a ChangeLog and pushed this to t
On 8/22/23 20:15, Keith Packard via Gcc-patches wrote:
Check for non-zero denorm in __adddf3. Need to check both the upper and
lower 32-bit chunks of a 64-bit float for a non-zero value when
checking to see if the value is -0.
Fix __addsf3 when the sum exponent is exactly 0xff to ensure that
On 8/13/23 20:11, Hans-Peter Nilsson wrote:
On Mon, 1 May 2023, Jeff Law wrote:
Spurred by Segher's RFC, I went ahead and tested several ports with LRA
enabled. Not surprisingly, many failed, but a few built their full set of
libraries successful and of those a few even ran
On 11/10/23 15:07, Florian Weimer wrote:
This change updates the gcc.c-torture/execute/ to avoid obsolete
language constructs. In the changed tests, use of the features
appears to be accidental, and updating allows the tests run with
the default compiler flags.
gcc/testsuite/
* gcc.
On 11/10/23 15:07, Florian Weimer wrote:
The execute tests use abort/exit to report failure/success, but
they generally do not declare these functions (or include ).
This change adds declarations as appropriate.
It would have been possible to switch to __builtin_abort and
__builtin_exit inste
On 11/10/23 15:07, Florian Weimer wrote:
gcc/testsuite/
* gcc.c-torture/compile/386.c: Compile with -std=gnu89.
* gcc.c-torture/compile/BUG1.c: Likewise.
* gcc.c-torture/compile/BUG11.c: Likewise.
* gcc.c-torture/compile/BUG16.c: Likewise.
* gcc.c-tortu
On 11/10/23 15:06, Florian Weimer wrote:
gcc/testsuite/
* gcc.c-torture/compile/BUG17.c (main): Add missing int
return type and missing void type.
* gcc.c-torture/compile/BUG18.c (main): Likewise. Call
__builtin_printf instead of printf.
* gcc.c-tortur
On 11/11/23 08:51, Richard Sandiford wrote:
Jeff Law writes:
On 11/7/23 17:35, Richard Sandiford wrote:
I could have sworn that there was something that checked that passes
left edge aux fields clear, but it looks like I misremembered. So I
probably need to stick a clear_aux_for_edges
On 11/11/23 08:54, Richard Sandiford wrote:
Jeff Law writes:
On 11/5/23 11:50, Richard Sandiford wrote:
The mode-switching pass assumed that all of an entity's modes
were mutually exclusive. However, the upcoming SME changes
have an entity with some overlapping modes, so that the
On 11/11/23 08:33, Richard Sandiford wrote:
Joern's code is a bit of a mess, but Jivan and I are slowly untangling
it from a correctness standpoint. It'll also need the usual cleanups.
Ah, nice! How configurable are the bit ranges? We might be able to use
something similar to track lanes
On 11/10/23 18:02, Keith Packard wrote:
I'm largely trusting your reputation on the fpgnulib changes. I won't
claim to know that code at all. The assembly bits were simple enough
that I could make out what you were doing relatively easily.
Thanks for that review -- m68k assembly isn't m
On 11/10/23 17:22, Patrick O'Neill wrote:
On 11/10/23 03:00, Prathamesh Kulkarni wrote:
On Thu, 5 Oct 2023 at 00:00, Brendan Shanks wrote:
Hi,
This patch implements pex_unix_exec_child using posix_spawn when
available.
This should especially benefit recent macOS (where vfork just calls
f
On 11/10/23 15:06, Florian Weimer wrote:
These tests use obsolete language constructs, but they are not
clearly targeting C89, either. So use -fpermissive to keep
future errors as warnings.
The reasons why obsolete constructs are used used vary from
test to test. Some tests deliberately exe
On 11/10/23 15:06, Florian Weimer wrote:
gcc/testsuite/
* gcc.c-torture/compile/20080613-1.c (hop_sendmsg): Call
__builtin_memcpy instead of memcpy.
* gcc.c-torture/compile/complex-6.c (bar): Declare.
* gcc.c-torture/compile/pr23445.c (__brelse): Declare.
On 11/11/23 05:11, Eric Botcazou wrote:
Hi,
IPA-CP can currently handle addresses of scalar constants (CONST_DECL) so this
extends that to addresses of constants in the pool (DECL_IN_CONSTANT_POOL).
Again this is helpful for so-called fat pointers in Ada, i.e. objects that are
semantically po
On 6/11/23 21:38, Jin Ma wrote:
Why do you need a different cost based on what's in the ready list?
Isn't the only property we're looking for whether or not the USE/CLOBBER
opens a live range?
Jeff
For this, I found that if I only look for the USE/CLOBBER that opens a live
range,
when th
On 8/14/23 05:22, Jin Ma wrote:
CLOBBER and USE does not represent real instructions, but in the
process of pipeline optimization, they will wait for transmission
in ready list like other insns, without considering resource
conflicts and cycles. This results in a multi-issue CPU architecture
t
On 11/12/23 10:41, Xi Ruoyao wrote:
On Sat, 2023-11-11 at 13:12 -0700, Jeff Law wrote:
On 8/14/23 05:22, Jin Ma wrote:
CLOBBER and USE does not represent real instructions, but in the
process of pipeline optimization, they will wait for transmission
in ready list like other insns, without
On 11/12/23 19:16, Jin Ma wrote:
Unfortunately this patch has triggered a bootstrap comparison failure on
loongarch64-linux-gnu: https://gcc.gnu.org/PR112497.
It's also causing simple build failures on other targets. For example
c6x-elf aborts when compiling gcc.c-torture/execute/pr82210 (a
On 11/13/23 01:15, juzhe.zh...@rivai.ai wrote:
I know the root cause is:
(reg:DI 15 a5 [orig:175 _103 ] [175])
(reg:DI 15 a5 [orig:174 _100 ] [174])
is considered as true on rtx_equal_p.
I think return note1 == note2; will simplify your codes and fix this issue.
NOTEs are not shared (look
On 11/13/23 07:47, Robin Dapp wrote:
As per Jeff's remark I'm going to push the attached.
Regards
Robin
Subject: [PATCH v4] RISC-V: vsetvl: Refine REG_EQUAL equality.
This patch enhances the equality check for REG_EQUAL notes in the vsetvl
pass by using the == operator instead of rtx_equa
On 11/12/23 23:53, Richard Biener wrote:
On Sun, Nov 12, 2023 at 12:12 AM Brendan Shanks wrote:
bad-mapper-1.C has been failing since the posix_spawn codepath was added
to libiberty, adjust the check to accept the changed error message.
Patch has been verified on x86_64 Linux.
OK
And pu
On 11/13/23 06:09, Florian Weimer wrote:
It turns out that permerror_opt is not directly usable for
-fpermissive in the C front end. The front end uses pedwarn
extensively, and pedwarns are not overridable by -Wno-* options,
yet permerrors are. Add new pedpermerror helpers that turn into
ped
On 11/13/23 06:10, Florian Weimer wrote:
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
* c-typeck.cc (build_conditional_expr): Use pedpermerror for
pointer/integer type mismatches, based on -Wint-conversion.
(pedwarn_pedpermerror_init, pe
On 11/13/23 06:10, Florian Weimer wrote:
In the future, it may make sense to avoid cascading errors from
the implicit declaration, especially its assumed int return type.
This change here only changes the kind of the diagnostic, not
its wording or consequences.
gcc/c/
* doc/invoke.te
On 11/13/23 06:11, Florian Weimer wrote:
There is a missed opportunity here to issue spelling diagnostics
in prototype declarations (e.g., for “extern int foo (int32t);”).
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
* c-decl.cc (warn_defaults_to): Cal
On 11/13/23 06:11, Florian Weimer wrote:
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
* c-typeck.cc (c_finish_return): Issue a permerror
for mismatching pointers to builtins. For mismatching
other pointers, issue a pedpermerror.
gcc/te
On 11/13/23 06:11, Florian Weimer wrote:
gcc/
* doc/invoke.texi (Warning Options): Document changes.
gcc/c/
* c-typeck.cc (build_conditional_expr): Use pedpermerror-
equivalent for pointer type mismatches in conditional
expression.
(convert_for_assign
On 11/12/23 20:22, pan2...@intel.com wrote:
From: Pan Li
Update in v4:
* Merge upstream and removed some independent changes.
Update in v3:
* Take known_le instead of known_lt for vector size.
* Return NULL_RTX when gap is not equal 0 and not constant.
Update in v2:
* Move vector type supp
On 11/13/23 13:22, Maciej W. Rozycki wrote:
On Mon, 16 Oct 2023, Maciej W. Rozycki wrote:
The testcase is generic enough I thought it wouldn't hurt to place it in
a generic part of the testsuite, where it has been verified to pass with
the `powerpc64le-linux-gnu', `riscv64-linux-gnu', and
On 11/12/23 20:37, Juzhe-Zhong wrote:
This patch optimization of combine 2 duplicate vectors when their elements are
not equal.
typedef char v16qi __attribute__ ((vector_size (16)));
void
foo (char a, char b, char *out)
{
v16qi v = {a, a, a, a, a, b, b, b, b, b, b, b, b, b, b, b};
*(v
On 11/12/23 23:02, Iain Sandoe wrote:
This patch set is not actually particualry new, I have been maintaining
it locally one Darwin branches and it has been tested on several versions
of Darwin both with and without Alex's __has_{feature, extension} patch.
This is one of the three most signif
On 11/14/23 15:08, Sebastian Huber wrote:
Sebastian Huber (4):
gcov: Remove TARGET_GCOV_TYPE_SIZE target hook
Add TARGET_HAVE_LIBATOMIC
gcov: Add gen_counter_update()
gcov: Improve -fprofile-update=atomic
gcc/c-family/c-cppbuiltin.cc | 4 +-
gcc/config/rtems.h | 2
On 11/14/23 22:30, Tom Tromey wrote:
The gdb tests of the libcc1 plugin have been failing lately. I
tracked this down to a crash trying to access an enum's underlying
type. This patch fixes the crash by setting this type.
libcc1/ChangeLog
* libcc1plugin.cc (plugin_build_enum_type):
On 9/8/23 04:49, Tatsuyuki Ishi via Gcc-patches wrote:
This implements TLS Descriptors (TLSDESC) as specified in [1].
In TLSDESC instruction sequence, the first instruction relocates against
the target TLS variable, while subsequent instructions relocates against
the address of the first. Suc
On 11/15/23 18:17, Fangrui Song wrote:
It seems that x86-64 supports non-adjacent code sequence. Writing the
pattern this way does not allow interleaving, but I assume
interleaving doesn't enable much.
It's of marginal benefit. We could always split them before scheduling
if it turned out
On 11/15/23 18:39, Tatsuyuki Ishi wrote:
As mentioned in the commit message, the use of relaxation-only labels
does not seem well supported in current GCC. Creating a label seems to
force a basic block and I’m not sure how we can avoid it.
If there’s a better way to implement this I’m ha
On 11/15/23 18:51, Tatsuyuki Ishi wrote:
On Nov 16, 2023, at 10:07, Jeff Law wrote:
Based on what I have read in the AArch64 backend, there are two ways to
do this: introduce a custom calling convention, or put in a RTX insn
that covers the whole sequence. Ideally we should do the
On 11/15/23 22:33, Fangrui Song wrote:
I have used this to check rtld and linker behavior. I think we need
some `scan-assembler`.
To make it a runnable test, some assembler feature check may be
needed. Perhaps Jeff can make some suggestion or contribute code!
TLS isn't really on my radar yet
On 11/16/23 10:54, John David Anglin wrote:
Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. Committed
to trunk.
This patch works around problem compiling python3.11 by improving
REG+D address handling. The change results in smaller code and
reduced register pressure.
Dave
---
hp
So looking for thoughts from the community on this one
Let's take this RTL:
(insn 10 9 11 2 (set (reg:SI 144)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_FRFLAGS)) "j.c":11:3 discrim 1 362 {riscv_frflags}
(nil))
(insn 11 10 55 2 (set (reg:DI 140
On 11/16/23 18:20, Sam James wrote:
Jeff, I don't suppose you could dig out the old bugs/commits just out of
interest?
That work goes back to the early 90s when I was primarily responsible
for the PA platform. But the core issue hasn't changed in that not
enough context is provided for re
On 11/17/23 01:27, John David Anglin wrote:
On 2023-11-16 10:00 p.m., Jeff Law wrote:
I'm not seeing any obvious problems in the gcc testsuite. It needs testing on
packages that do extensive
floating point calculations.
OK, I'll focus on those.
THe more likely scenario is xmp
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. So
the comb
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_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")]
VMULH)
On 11/16/23 15:36, Antoni Boucher wrote:
Hi.
This patch fixes a RTL bug when using some target-specific builtins in
libgccjit (bug 112576).
The test use a function from an unmerged patch:
https://gcc.gnu.org/pipermail/jit/2023q1/001605.html
Thanks for the review!
The natural question here is
On 11/17/23 14:08, Antoni Boucher wrote:
In contrast with the other frontends, libgccjit can be executed
multiple times in a row in the same process.
Yup. I'm aware of that. Even so calling init_emit_once more than one
time still seems wrong.
jeff
On 11/17/23 16:16, 钟居哲 wrote:
>> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
may also need to add '^' to the punct_valid_p hook. But yes, this is
the preferred way to go when all we need to do is prefix the instruction
with "th.".
No. I don't think we need to add
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 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 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&#x
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
On 11/19/23 04:24, Maciej W. Rozycki wrote:
Remove our RISC-V-specific `order_operator' predicate, which is exactly
the same as generic `ordered_comparison_operator' one.
gcc/
* config/riscv/predicates.md (order_operator): Remove predicate.
* config/riscv/riscv.cc (ris
On 11/19/23 00:30, Alexandre Oliva wrote:
I've recently patched scev-3.c and scev-5.c because it only passed by
accident on ia32. It also fails on some (but not all) arm-eabi
variants. It seems hard to characterize the conditions in which the
optimization is supposed to pass, but expecting
On 11/19/23 00:36, Alexandre Oliva wrote:
On targets that have -fshort-enums enabled by default, the type casts
in the pr108251 analyzer tests warn that the byte-aligned enums may
not be sufficiently aligned to be a struct connection *. The function
can't know better, the warning is reasonab
On 11/18/23 22:38, Maciej W. Rozycki wrote:
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-conv
On 11/18/23 22:38, Maciej W. Rozycki wrote:
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 seque
On 11/18/23 22:38, Maciej W. Rozycki wrote:
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 bran
On 11/18/23 22:39, Maciej W. Rozycki wrote:
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-con
On 11/18/23 22:39, Maciej W. Rozycki wrote:
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 con
On 11/18/23 22:39, Maciej W. Rozycki wrote:
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, whic
On 11/18/23 22:40, Maciej W. Rozycki wrote:
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-convers
On 11/18/23 22:40, Maciej W. Rozycki wrote:
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 ori
On 11/18/23 22:40, Maciej W. Rozycki wrote:
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.
OK
jeff
On 11/18/23 22:40, Maciej W. Rozycki wrote:
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, o
On 11/18/23 22:40, Maciej W. Rozycki wrote:
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 wo
On 11/18/23 22:41, Maciej W. Rozycki wrote:
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 orig
On 11/18/23 22:41, Maciej W. Rozycki wrote:
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 transform
On 11/18/23 22:41, Maciej W. Rozycki wrote:
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 wou
On 11/18/23 22:41, Maciej W. Rozycki wrote:
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 origi
On 11/18/23 22:42, Maciej W. Rozycki wrote:
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 i
On 11/18/23 22:42, Maciej W. Rozycki wrote:
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
condi
On 11/18/23 22:40, Maciej W. Rozycki wrote:
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.
You could characterize it that way. It was mostly a desire to not muck
On 11/18/23 22:36, Maciej W. Rozycki wrote:
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 h
They have a REG destination and an UNSPEC source, but the REG
has no mode in the pattern. Since it wasn't clear what mode to give the
UNSPEC, I left those alone.
Pushing to the trunk.
jeff
commit 07da9b7f13c92a21d12172a9df85ad762591b998
Author: Jeff Law
Date: Sun Nov 19 11:56:
On 11/18/23 22:42, Maciej W. Rozycki wrote:
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-conversi
On 11/18/23 22:42, Maciej W. Rozycki wrote:
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
On 11/18/23 22:42, Maciej W. Rozycki wrote:
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 tha
On 11/18/23 22:43, Maciej W. Rozycki wrote:
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 mak
On 11/18/23 22:43, Maciej W. Rozycki wrote:
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
On 11/18/23 22:43, Maciej W. Rozycki wrote:
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
On 11/18/23 22:43, Maciej W. Rozycki wrote:
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 th
SCHED_MACRO_FUSION_P): Define.
(TARGET_SCHED_MACRO_FUSION_PAIR_P): Likewise.
(extract_base_offset_in_addr): Moved into riscv.cc from...
* config/riscv/thead.cc: Here.
Co-authored-by: Raphael Zinsly
Co-authored-by: Jeff Law
diff --git a/gc
On 11/16/23 22:12, Li Xu wrote:
From: xuli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537
-mmemcpy-strategy=[auto|libcall|scalar|vector]
auto: Current status, use scalar or vector instructions.
libcall: Always use a library call.
scalar: Only use scalar instructions.
vector: Only use v
On 11/16/23 19:53, Andrew Carlotti wrote:
This patch changes the handling of mutual exclusions involving the
target and target_clones attributes to use the generic attribute
exclusion lists. Additionally, the duplicate handling for the
always_inline and noinline attribute exclusion is removed
On 11/12/23 07:52, Richard Sandiford wrote:
The main way of enforcing registers to be aligned is through
HARD_REGNO_MODE_OK. But this is a global property that applies
to all operands. A given (regno, mode) pair is either globally
valid or globally invalid.
This patch instead adds a way of
On 11/12/23 07:52, Richard Sandiford wrote:
The main (but simplest) part of this patch makes constrain_operands
take register filters into account.
The rest of the patch adds register filter information to
operand_alternative. Generally, if two register constraints
have different register fi
On 11/12/23 07:52, Richard Sandiford wrote:
This patch adds a target-independent aligned_register_operand
predicate, for use with register constraints that use filters
to impose an alignment. The definition deliberately jetisons
some of the historical baggage in general_operand.
gcc/
On 11/19/23 04:27, Maciej W. Rozycki wrote:
We have an issue with `scan-assembler-times' handling expressions using
subexpressions as produced by capturing parentheses `()' in an odd way,
and one that is inconsistent with `scan-assembler', `scan-assembler-not',
etc. The problem comes from cal
This is work originally started by Joern @ Embecosm.
There's been a long standing sense that we're generating too many
sign/zero extensions on the RISC-V port. REE is useful, but it's really
focused on a relatively narrow part of the extension problem.
What Joern's patch does is introduce a
On 11/19/23 18:22, Oleg Endo wrote:
On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
This is work originally started by Joern @ Embecosm.
There's been a long standing sense that we're generating too many
sign/zero extensions on the RISC-V port. REE is useful, but it's re
On 11/19/23 19:23, Xi Ruoyao wrote:
On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
This is work originally started by Joern @ Embecosm.
There's been a long standing sense that we're generating too many
sign/zero extensions on the RISC-V port. REE is useful, but it's real
On 11/19/23 19:33, Alexandre Oliva wrote:
I got spurious fails of tests that required arm_thumb1_movt_ok on a
target cpu that did not support movt. Looking into it, I found the
arm_movt property to have been cut&pasted into various procs that
checked for different properties. They shouldn't
On 11/19/23 20:32, Xi Ruoyao wrote:
On Sun, 2023-11-19 at 19:52 -0700, Jeff Law wrote:
/* snip */
Unfortunately, I get some ICE building stage 1 libgcc with this patch on
loongarch64-linux-gnu:
during RTL pass: ext_dce
../../../gcc/libgcc/libgcc2.c: In function ‘__absvdi2’:
../../../gcc
On 10/30/23 21:35, Fei Gao wrote:
So just a few notes to further illustrate why I'm currently looking to
take the VRULL+Ventana implementation. The code above would be much
better handled by just calling noce_emit_cmove. noce_emit_cmove will go
through the conditional move expander. So any
1101 - 1200 of 15777 matches
Mail list logo
