From: Pan Li
This patch would like to add strict check for imm operand of .SAT_SUB
matching. We have no type checking for imm operand in previous, which
may result in unexpected IL to be catched by .SAT_SUB pattern.
We leverage the int_fits_type_p here to make sure the imm operand is
a int type
From: Pan Li
This patch would like to add strict check for imm operand of .SAT_SUB
matching. We have no type checking for imm operand in previous, which
may result in unexpected IL to be catched by .SAT_SUB pattern.
We leverage the int_fits_type_p here to make sure the imm operand is
a int type
Thanks Jeff.
> But I would expect that may be beneficial on other targets as well.
I think x86 have the similar insn for saturation, for example as paddsw in
below link.
https://www.felixcloutier.com/x86/paddsb:paddsw
And the backend of x86 implemented some of them already I bet, like usadd,
us
On 8/27/24 3:17 AM, Xianmiao Qu wrote:
Currently, in RV32, even with the D extension enabled, the cost of DFmode
register moves is still set to 'COSTS_N_INSNS (2)'. This results in the
'lower-subreg' pass splitting DFmode register moves into two SImode SUBREG
register moves, leading to the gen
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: Monday, August 26, 2024 4:21 PM
> To: Thomas Schwinge ; gcc-patches@gcc.gnu.org
> Subject: [nvptx] Fix code-gen for alias attribute
>
> External email: Use caution opening links or attachments
>
>
> Hi,
> For the following test (a
This is a small bug in the ext-dce code's handling of promoted subregs.
Essentially when we see a promoted subreg we need to make additional bit
groups live as various parts of the RTL path know that an extension of a
suitably promoted subreg can be trivially eliminated.
When I added support
On 9/1/24 8:50 PM, Li, Pan2 wrote:
Thanks Jeff for comments.
OK. Presumably the code you're getting here is more efficient than
whatever standard expansion would provide? If so, should we be looking
at moving some of this stuff into generic expanders? I don't really see
anything all that
Thanks Jeff for comments.
> OK. Presumably the code you're getting here is more efficient than
> whatever standard expansion would provide? If so, should we be looking
> at moving some of this stuff into generic expanders? I don't really see
> anything all that target specific here.
Mostly
On Tue, Aug 27, 2024 at 1:11 PM H.J. Lu wrote:
>
> Update analyze_parms not to disable function parameter analysis for
> -ffat-lto-objects. Tested on x86-64, there are no differences in zstd
> with "-O2 -flto=auto" -g "vs -O2 -flto=auto -g -ffat-lto-objects".
>
> PR ipa/116410
> *
On Mon, Aug 26, 2024 at 2:43 PM Haochen Jiang wrote:
>
> Hi all,
>
> I have just commited AVX10.2 new instructions patches into trunk hours
> ago. The next and final part for AVX10.2 upstream is to optimize code
> with AVX10.2 new instructions.
>
> In this patch series, it will contain the followi
On Sun, Sep 1, 2024 at 4:27 PM Kugan Vivekanandarajah
wrote:
>
> Hi Andrew.
>
> > On 28 Aug 2024, at 2:23 pm, Andrew Pinski wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, Aug 27, 2024 at 8:54 PM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi Richard,
Hi Andrew.
> On 28 Aug 2024, at 2:23 pm, Andrew Pinski wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Tue, Aug 27, 2024 at 8:54 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>> Thanks for the reply.
>>
>>> On 27 Aug 2024, at 7:05 pm, Richard Biener
Hi Martin,
On Sun, Sep 01, 2024 at 11:51:10AM GMT, Martin Uecker wrote:
>
> Alex,
>
> I am all for making things more consistent, but there is also a cost
> to changing stuff too much. length is the established
> term in most programming languages and I would recommend to stick
> to it.
>
>
Hi Jason,
On 26 Aug 2024, at 19:23, Jason Merrill wrote:
> On 8/25/24 12:37 PM, Simon Martin wrote:
>> On 24 Aug 2024, at 23:59, Simon Martin wrote:
>>> On 24 Aug 2024, at 15:13, Jason Merrill wrote:
>>>
On 8/23/24 12:44 PM, Simon Martin wrote:
> We currently emit an incorrect -Woverload
On 9/1/24 9:47 AM, Filip Kastl wrote:
On Sun 2024-09-01 09:25:07, Jeff Law wrote:
On 9/1/24 9:19 AM, Filip Kastl wrote:
(I'm Cc-ing Diego since he originally contributed the VRP pass and Jeff because
I've seen him in git blame on many lines of vr-values.cc around the place I
would like to
This came up in discussion of an earlier patch.
I'm in two minds as to whether it's a good idea or not - the underlying
issue being that libubsan does not yet (AFAICT) have the concept of a
coroutine, so that the diagnostics are not very specific and might appear
strange (i.e. "execution reached t
On Sun 2024-09-01 09:25:07, Jeff Law wrote:
>
>
> On 9/1/24 9:19 AM, Filip Kastl wrote:
> > (I'm Cc-ing Diego since he originally contributed the VRP pass and Jeff
> > because
> > I've seen him in git blame on many lines of vr-values.cc around the place I
> > would like to make modifications)
>
On 8/29/24 12:25 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to support the scalar signed ssadd pattern
for the RISC-V backend. Aka
Form 1:
#define DEF_SAT_S_ADD_FMT_1(T, UT, MIN, MAX) \
T __attribute__((noinline)) \
sat_s_add_##T##_fmt_1 (T x,
On 8/29/24 2:12 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to add test cases for the unsigned scalar quad and
oct .SAT_TRUNC form 2. Aka:
Form 2:
#define DEF_SAT_U_TRUC_FMT_2(NT, WT) \
NT __attribute__((noinline)) \
sat_u_truc_##WT##_to_##NT##_
On 9/1/24 9:19 AM, Filip Kastl wrote:
(I'm Cc-ing Diego since he originally contributed the VRP pass and Jeff because
I've seen him in git blame on many lines of vr-values.cc around the place I
would like to make modifications)
Hello,
In this RFC I'd like to propose the following: When the v
(I'm Cc-ing Diego since he originally contributed the VRP pass and Jeff because
I've seen him in git blame on many lines of vr-values.cc around the place I
would like to make modifications)
Hello,
In this RFC I'd like to propose the following: When the value range statement
simplification machine
On 8/29/24 9:04 PM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to add test cases for the unsigned vector .SAT_ADD
when one of the operand is IMM.
Form 3:
#define DEF_VEC_SAT_U_ADD_IMM_FMT_3(T, IMM) \
T __attribute__((noinline))
On 8/30/24 1:23 AM, pan2...@intel.com wrote:
From: Pan Li
In previous, we have some specially handling for both the .SAT_ADD and
.SAT_SUB for unsigned int. There are similar to take care of SImode
in RV64 for zero extend. Thus refactor these two helper function
into one for possible code d
Alex,
I am all for making things more consistent, but there is also a cost
to changing stuff too much. length is the established
term in most programming languages and I would recommend to stick
to it.
Note that it is not true that the standard consistently refers to
char a[3][n]
as a VLA
Hi Jens, Martin,
On Wed, Aug 14, 2024 at 05:44:57PM GMT, Jens Gustedt wrote:
> Am 14. August 2024 16:47:32 MESZ schrieb Alejandro Colomar :
> > > > I was thinking of renaming the proposal to elementsof(), to avoid
> > > > confusion between length of an array and length of a string. Would you
> >
25 matches
Mail list logo
