On Mon, 21 Nov 2022, Jeff Law wrote:
> They're writing assembly code -- in my book that means they'd better have a
> pretty good understanding of the architecture, its limitations and quirks.
That GCC ties together optimization and inline asm interface via its internal
TARGET_MODE_REP_EXTENDED
On 11/21/22 06:49, Alexander Monakov wrote:
On Sun, 20 Nov 2022, Jeff Law wrote:
The concern, as far as I understand would be the case where the
assembly-sequence leaves an incompatible extension in the register.
Right. The question in my mind is whether or not the responsibility should be
On Sun, 20 Nov 2022, Jeff Law wrote:
> > The concern, as far as I understand would be the case where the
> > assembly-sequence leaves an incompatible extension in the register.
>
> Right. The question in my mind is whether or not the responsibility should be
> on the compiler or on the develop
On 11/4/22 17:00, Philipp Tomsich wrote:
Alexander,
I had missed your comment until now.
On Tue, 6 Sept 2022 at 13:39, Alexander Monakov wrote:
On Mon, 5 Sep 2022, Philipp Tomsich wrote:
+riscv_mode_rep_extended (scalar_int_mode mode, scalar_int_mode
mode_rep)
+{
+ /* On 64-bit targets
On Wed, 9 Nov 2022, Philipp Tomsich wrote:
> > To give a specific example that will be problematic if you go far enough
> > down
> > the road of matching MIPS64 behavior:
> >
> > long f(void)
> > {
> > int x;
> > asm("" : "=r"(x));
> > return x;
> > }
> >
> > here GCC (unlike LLVM) om
On Mon, 7 Nov 2022 at 14:55, Alexander Monakov wrote:
>
>
>
> On Sat, 5 Nov 2022, Philipp Tomsich wrote:
>
> > Alexander,
> >
> > I had missed your comment until now.
>
> Please make sure to read replies from Jeff and Palmer as well (their responses
> went to gcc-patches with empty Cc list):
> htt
On Sat, 5 Nov 2022, Philipp Tomsich wrote:
> Alexander,
>
> I had missed your comment until now.
Please make sure to read replies from Jeff and Palmer as well (their responses
went to gcc-patches with empty Cc list):
https://inbox.sourceware.org/gcc-patches/ba895f78-7f47-0f4-5bfe-e21893c4...@
Alexander,
I had missed your comment until now.
On Tue, 6 Sept 2022 at 13:39, Alexander Monakov wrote:
>
> On Mon, 5 Sep 2022, Philipp Tomsich wrote:
>
> > +riscv_mode_rep_extended (scalar_int_mode mode, scalar_int_mode
mode_rep)
> > +{
> > + /* On 64-bit targets, SImode register values are sig
On Fri, 16 Sep 2022 16:48:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 9/6/22 05:39, Alexander Monakov via Gcc-patches wrote:
On Mon, 5 Sep 2022, Philipp Tomsich wrote:
+riscv_mode_rep_extended (scalar_int_mode mode, scalar_int_mode mode_rep)
+{
+ /* On 64-bit targets, SImode register v
On 9/6/22 05:39, Alexander Monakov via Gcc-patches wrote:
On Mon, 5 Sep 2022, Philipp Tomsich wrote:
+riscv_mode_rep_extended (scalar_int_mode mode, scalar_int_mode mode_rep)
+{
+ /* On 64-bit targets, SImode register values are sign-extended to DImode. */
+ if (TARGET_64BIT && mode == SIm
On Mon, 5 Sep 2022, Philipp Tomsich wrote:
> +riscv_mode_rep_extended (scalar_int_mode mode, scalar_int_mode mode_rep)
> +{
> + /* On 64-bit targets, SImode register values are sign-extended to DImode.
> */
> + if (TARGET_64BIT && mode == SImode && mode_rep == DImode)
> +return SIGN_EXTEND
TARGET_MODE_REP_EXTENDED is supposed to match LOAD_EXTEND_OP, so this
adds an implementation using the same logic as in LOAD_EXTEND_OP.
This reduces the number of extension operations, as evidenced in the
reduction of dynamic instructions for the xz benchmark in SPEC CPU:
# dy
12 matches
Mail list logo
