On Fri, Nov 16, 2018 at 10:09:59AM -0600, Segher Boessenkool wrote:
> On Mon, Nov 12, 2018 at 11:54:58AM -0700, Jeff Law wrote:
> > On 11/12/18 10:52 AM, Andrew Stubbs wrote:
> > > If there are two instructions that both have an UNSPEC_VOLATILE, will
> > > combine coalesce them into one in the comb
On Mon, Nov 12, 2018 at 11:54:58AM -0700, Jeff Law wrote:
> On 11/12/18 10:52 AM, Andrew Stubbs wrote:
> > If there are two instructions that both have an UNSPEC_VOLATILE, will
> > combine coalesce them into one in the combined pattern?
> I think you can put a different constant on each.
combine (
The guideline I would give to determine if you're vulnerable... Do you
have speculation, including the ability to speculate past a memory
operation, branch prediction, memory caches and high resolution timer
(ie, like a cycle timer). If you've got those, then the processor is
likely vulnerable t
On 14/11/2018 22:30, Jeff Law wrote:
There's a particular case that has historically been problematical.
If you have this kind of sequence in the epilogue
restore register using FP
move fp->sp (deallocates frame)
return
Under certain circumstances the scheduler can swa
On 11/12/18 5:53 AM, Andrew Stubbs wrote:
> On 09/11/2018 19:39, Jeff Law wrote:
>>> +
>>> +/* Generate epilogue. Called from gen_epilogue during
>>> pro_and_epilogue pass.
>>> +
>>> + See gcn_expand_prologue for stack details. */
>>> +
>>> +void
>>> +gcn_expand_epilogue (void)
>> You probably
On Tue, Nov 13, 2018 at 10:23:12AM +, Andrew Stubbs wrote:
> Now that Segher says the combine issue is a bug,
Well, first show what really happens; if it really deletes a USE, that
is a bug yes. rtl.def says:
/* Indicate something is used in a way that we don't want to explain.
For exampl
On 12/11/2018 18:54, Jeff Law wrote:
On 11/12/18 10:52 AM, Andrew Stubbs wrote:
On 12/11/2018 17:20, Segher Boessenkool wrote:
If you don't want useless USEs deleted, use UNSPEC_VOLATILE instead?
Or actually use the register, i.e. as input to an actually needed
instruction.
They're not useles
On 11/12/18 10:52 AM, Andrew Stubbs wrote:
> On 12/11/2018 17:20, Segher Boessenkool wrote:
>> If you don't want useless USEs deleted, use UNSPEC_VOLATILE instead?
>> Or actually use the register, i.e. as input to an actually needed
>> instruction.
>
> They're not useless. If we want to do scalar
On Mon, Nov 12, 2018 at 05:52:25PM +, Andrew Stubbs wrote:
> On 12/11/2018 17:20, Segher Boessenkool wrote:
> >If you don't want useless USEs deleted, use UNSPEC_VOLATILE instead?
> >Or actually use the register, i.e. as input to an actually needed
> >instruction.
>
> They're not useless.
> >
On 12/11/2018 17:20, Segher Boessenkool wrote:
If you don't want useless USEs deleted, use UNSPEC_VOLATILE instead?
Or actually use the register, i.e. as input to an actually needed
instruction.
They're not useless. If we want to do scalar operations in vector
registers (and we often do, on th
On Mon, Nov 12, 2018 at 12:53:26PM +, Andrew Stubbs wrote:
> >>+/* Implement TARGET_LEGITIMATE_COMBINED_INSN.
> >>+
> >>+ Return false if the instruction is not appropriate as a combination
> >>of two
> >>+ or more instructions. */
> >>+
> >>+bool
> >>+gcn_legitimate_combined_insn (rtx_in
On 09/11/2018 19:39, Jeff Law wrote:
+
+/* Generate epilogue. Called from gen_epilogue during pro_and_epilogue pass.
+
+ See gcn_expand_prologue for stack details. */
+
+void
+gcn_expand_epilogue (void)
You probably need a barrier in here to ensure that the scheduler doesn't
move an aliased
On 9/5/18 7:42 AM, Andrew Stubbs wrote:
> This part initially failed to send due to size.
>
> Here's part 2.
>
> 0021-gcn-port-pt2.patch
[ ... ]
You've already addressed Joseph's comments in a follow-up.
>
> diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
> new file mode 100644
> inde
On Wed, 12 Sep 2018, Andrew Stubbs wrote:
> > What if the host is x86_64 with the x32 ABI? If the requirement is for
> > various types to be the same between the host and GCN, I'd expect that x32
> > ABI on the host means it is unsuitable for using gcn-run. Or are the
> > requirements for compat
On 12/09/18 16:32, Joseph Myers wrote:
+ case "$host" in
+ x86_64*-*-linux-gnu )
+ if test "$ac_res" != no; then
+ extra_programs="${extra_programs} gcn-run\$(exeext)"
+ fi
ac_res is a generic autoconf variable used by a lot of tests
On Wed, 12 Sep 2018, Andrew Stubbs wrote:
> > I'd expect this to fail on non-Unix configurations that don't have -ldl,
> > and thus to need appropriate conditionals / configure tests to avoid that
> > build failure.
>
> The attached diff from the previous patch should address these issues, I hope
On 05/09/18 15:22, Joseph Myers wrote:
In cases like this with alternative diagnostic messages using ?:, you need
to mark up each message with G_() so they both get extracted for
translation by exgettext.
[...]
This concatenation with a macro won't work with exgettext extracting
messages for
On Tue, 11 Sep 2018, Andrew Stubbs wrote:
> On 05/09/18 15:44, Joseph Myers wrote:
> > On Wed, 5 Sep 2018, Andrew Stubbs wrote:
> >
> > > I suppose someone might choose to compile things on an alternative system
> > > for
> > > running on a compatible system, in which case we'd want to simply ski
On 05/09/18 15:44, Joseph Myers wrote:
On Wed, 5 Sep 2018, Andrew Stubbs wrote:
I suppose someone might choose to compile things on an alternative system for
running on a compatible system, in which case we'd want to simply skip this
binary.
How does one normally do this?
I'd expect a config
On Wed, 5 Sep 2018, Andrew Stubbs wrote:
> I suppose someone might choose to compile things on an alternative system for
> running on a compatible system, in which case we'd want to simply skip this
> binary.
>
> How does one normally do this?
I'd expect a configure test plus makefile conditiona
On 05/09/18 15:22, Joseph Myers wrote:
+gcn-run$(exeext): gcn-run.o
+ +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ $< -ldl
I'd expect this to fail on non-Unix configurations that don't have -ldl,
and thus to need appropriate conditionals / configure tests to avoid that
build failure.
W
On Wed, 5 Sep 2018, Andrew Stubbs wrote:
> + warning_at (decl ? DECL_SOURCE_LOCATION (decl) : UNKNOWN_LOCATION,
> + OPT_Wopenacc_dims,
> + (dims[GOMP_DIM_VECTOR]
> +? "using vector_length (64), ignoring %d"
> +: "usi
22 matches
Mail list logo
