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
> > wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, Aug 27, 2024 at 8:23 AM Kugan Vivekanandarajah
From: Pan Li
The .SAT_ADD has 2 operand, when one of the operand may be INTEGER_CST.
For example _1 = .SAT_ADD (_2, 9) comes from below sample code.
Form 3:
#define DEF_VEC_SAT_U_ADD_IMM_FMT_3(T, IMM) \
T __attribute__((noinline))
While working on PR 114224, I found it would be useful to dump the
different costs of the expansion to make easier to understand why one
was chosen over the other.
Bootstrapped and tested on x86_64-linux-gnu.
Build and tested for aarch64-linux-gnu.
gcc/ChangeLog:
* internal-fn.cc (expand
While looking into some popcount related I noticed that the popcount
cost is not modeled at all. This adds both the vector and scalar (for CSSC)
costs. For CSSC, we default to `COSTS_N_INSNS (3)` based on the Ampere1B's
cycle count that is found from LLVM's model.
Built and tested for aarch64-linu
While working on PR 114224 (popcount costs is not modeled), I noticed
that addv (vector reduction add) was not handled either. This adds the handling
there. Some of the extends are part of the instructions so we need to handle
those
too.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch6
Thanks for the ping - It's running now:
https://github.com/ewlu/gcc-precommit-ci/issues/2146
Patrick
On 8/27/24 18:22, Li, Pan2 wrote:
Hi Patrick,
Could you please help to re-trigger the pre-commit?
Thanks in advance!
Pan
-Original Message-
From: Patrick O'Neill
Sent: Tuesday, Augu
version.syn#2 requires to define
__cpp_lib_allocator_traits_is_always_equal.
The attached patch therefore defines the
__glibcxx_want_allocator_traits_is_always_equal macro to get the
definition of the feature-test macro from .
This is not isolated only to though. The standard requires the
foll
committed to trunk.
> You don't need an OK of course but LGTM.
>
> When I found another instance of this I was thinking about having
> exhaustive self tests for those attributes. Maybe a good learning
> exercise?
Yeah, that would be great, otherwise it's not really easy to maintain
those attribu
On Tue, Aug 27, 2024 at 7:17 PM Richard Sandiford
wrote:
>
> The documentation of ASM_INPUT_P implied that the flag has no
> effect on ASM_EXPRs that have operands (and which therefore must be
> extended asms). In fact we require ASM_INPUT_P to be false for all
> extended asms.
Quite a bad name
101 - 109 of 109 matches
Mail list logo