What is volatile instructions? Can you give us an example?
Check volatile_insn_p. AFAIK there are two classes of volatile instructions:
* volatile asm
* unspec volatiles (target-specific instructions for e.g. protecting
function prologues)
-Y
>> Asms without outputs are automatically volatile. So there ought be
zero change
>> with and without the explicit use of the __volatile__ keyword.
>
> That’s what the documentation says but it wasn’t actually true
> as of a couple of releases ago, as I recall.
Looks like 2005:
$ git annotate
Richard Sandiford writes:
> Matthew Fortune writes:
> >> Matthew Fortune writes:
> >> >> > Sorry, forgot about that. In that case maybe program headers
> >> >> > would be best, like you say. I.e. we could use a combination of
> >> >> > GNU attributes and a new program header, with the program
On 3 March 2014 20:44, Torvald Riegel wrote:
> On Sun, 2014-03-02 at 04:05 -0600, Peter Sewell wrote:
>> On 1 March 2014 08:03, Paul E. McKenney wrote:
>> > On Sat, Mar 01, 2014 at 04:06:34AM -0600, Peter Sewell wrote:
>> >> Hi Paul,
>> >>
>> >> On 28 February 2014 18:50, Paul E. McKenney
>> >>
On Tue, Mar 04, 2014 at 11:00:32AM -0800, Paul E. McKenney wrote:
> On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote:
> > xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com
> > X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA)
> >
> > On Mon, 2014-03-03 at 11:20 -0800, Paul
On Mar 4, 2014, at 2:30 PM, Richard Henderson wrote:
> On 03/04/2014 01:23 AM, Richard Biener wrote:
>> Doesn't sound like a bug but a feature. We can move
>> asm ("" : : : "memory") around freely up to the next/previous
>> instruction involving memory.
>
> Asms without outputs are automatical
Matthew Fortune writes:
>> Matthew Fortune writes:
>> >> > Sorry, forgot about that. In that case maybe program headers would
>> >> > be best, like you say. I.e. we could use a combination of GNU
>> >> > attributes and a new program header, with the program header
>> >> > hopefully being more g
> Matthew Fortune writes:
> >> > Sorry, forgot about that. In that case maybe program headers would
> >> > be best, like you say. I.e. we could use a combination of GNU
> >> > attributes and a new program header, with the program header
> >> > hopefully being more general than for just this case
On 03/04/2014 01:23 AM, Richard Biener wrote:
> Doesn't sound like a bug but a feature. We can move
> asm ("" : : : "memory") around freely up to the next/previous
> instruction involving memory.
Asms without outputs are automatically volatile. So there ought be zero change
with and without the
On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote:
> xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com
> X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA)
>
> On Mon, 2014-03-03 at 11:20 -0800, Paul E. McKenney wrote:
> > On Mon, Mar 03, 2014 at 07:55:08PM +0100, Torvald Ri
Thomas Preudhomme writes:
>> I think the ability to detect the case of generating ABI agnostic
>> code would be useful for other architectures too.
>
> I do not know the other architecture to know if that is the case but
> according to what you said for MIPS it seems to be the case. Right now I
Matthew Fortune writes:
>> > Sorry, forgot about that. In that case maybe program headers would be
>> > best, like you say. I.e. we could use a combination of GNU attributes
>> > and a new program header, with the program header hopefully being more
>> > general than for just this case. I suppo
On Wed, 5 Mar 2014, Thomas Preudhomme wrote:
> Right. It's actually quite simple. As soon as you meet a function which passes
> or returns a float then you can mark the whole module as not agnostic and fall
> back to the usual behavior. If you arrive at the end of a compiling unit
> without encout
On Mon, 3 Mar 2014, Richard Biener wrote:
How do I restrict some subexpression to have
a single use?
This kind of restrictions come via the valueize() hook - simply
valueize to NULL_TREE to make the match fail (for example
SSA_NAME_OCCURS_IN_ABNORMAL_PHI could be made fail that way).
Shouldn
Le 2014-03-04 19:14, Matthew Fortune a écrit :
Hi Thomas,
Hi Matthew,
Do you particularly need a switch for this? You could view this as
simply relaxing the ABI requirements of a module, a switch would only
serve to enforce the need for a compatible ABI and error if not. If
you build somethi
On Tue, Mar 04, 2014 at 12:08:19PM +0100, Richard Biener wrote:
> On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa
> wrote:
> > On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
> >> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
> >> >> > So the bug was probably fixed more t
On Mon, 3 Mar 2014, Kai Tietz wrote:
> 2014-03-03 12:33 GMT+01:00 Richard Biener :
> > On Fri, 28 Feb 2014, Kai Tietz wrote:
> >
> >> Hmm, this all reminds me about the approach Andrew Pinski and I came
> >> up with two years ago.
> >
> > You are talking about the gimple folding interface? Yes,
Thanks Maxim,
There is a tentative plan to merge the concepts branch into trunk, and
that would probably be at the end of the summer or fall, so that might
fit nicely. It probably wouldn't hurt to have the students apply,
regardless of the final decisions. Writing proposals is good
experience.
I'
On Tue, Mar 4, 2014 at 1:01 PM, Hans-Peter Nilsson wrote:
> On Tue, 4 Mar 2014, Yury Gribov wrote:
>> Richard wrote:
>> > volatile __asm__("":::"memory")
>> >
>> > is a memory barrier and a barrier for other volatile instructions.
>>
>> AFAIK asm without output arguments is implicitly marked as vo
On Tue, 4 Mar 2014, Yury Gribov wrote:
> Richard wrote:
> > volatile __asm__("":::"memory")
> >
> > is a memory barrier and a barrier for other volatile instructions.
>
> AFAIK asm without output arguments is implicitly marked as volatile. So it may
> not be needed in barrier() at all.
Yes, exactl
Richard wrote:
> volatile __asm__("":::"memory")
>
> is a memory barrier and a barrier for other volatile instructions.
AFAIK asm without output arguments is implicitly marked as volatile. So
it may not be needed in barrier() at all.
-Y
On Tue, Mar 04, 2014 at 12:08:19PM +0100, Richard Biener wrote:
> On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa
> wrote:
> > On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
> >> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
> >> >> > So the bug was probably fixed more t
Hi Thomas,
Do you particularly need a switch for this? You could view this as simply
relaxing the ABI requirements of a module, a switch would only serve to enforce
the need for a compatible ABI and error if not. If you build something for a
soft-float ABI and never actually trigger any of the
On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa
wrote:
> On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
>> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
>> >> > So the bug was probably fixed more than 15 years ago.
>> > Probably :)
>> >
>> > But the __volatile__ shoud do
On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
> >> > So the bug was probably fixed more than 15 years ago.
> > Probably :)
> >
> > But the __volatile__ shoud do no harm and shouldn't influence code
> > generation in any way, no?
On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
>> > So the bug was probably fixed more than 15 years ago.
> Probably :)
>
> But the __volatile__ shoud do no harm and shouldn't influence code
> generation in any way, no?
Of course it will: it's a barrier.
Andrew.
On Tue, Mar 04, 2014 at 09:19:40AM +, Jonathan Wakely wrote:
> On 4 March 2014 09:17, Hannes Frederic Sowa
> wrote:
> > On Tue, Mar 04, 2014 at 10:10:21AM +0100, Richard Biener wrote:
> >> On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian wrote:
> >> > Hi,
> >> > in include/linux/compiler-gcc.
On Tue, Mar 4, 2014 at 10:19 AM, Jonathan Wakely wrote:
> On 4 March 2014 09:17, Hannes Frederic Sowa
> wrote:
>> On Tue, Mar 04, 2014 at 10:10:21AM +0100, Richard Biener wrote:
>>> On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian wrote:
>>> > Hi,
>>> > in include/linux/compiler-gcc.h :
>>> >
>>
On 4 March 2014 09:17, Hannes Frederic Sowa wrote:
> On Tue, Mar 04, 2014 at 10:10:21AM +0100, Richard Biener wrote:
>> On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian wrote:
>> > Hi,
>> > in include/linux/compiler-gcc.h :
>> >
>> > /* Optimization barrier */
>> > /* The "volatile" is due to gcc
On Tue, Mar 04, 2014 at 10:10:21AM +0100, Richard Biener wrote:
> On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian wrote:
> > Hi,
> > in include/linux/compiler-gcc.h :
> >
> > /* Optimization barrier */
> > /* The "volatile" is due to gcc bugs */
> > #define barrier() __asm__ __volatile__("": : :"m
On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian wrote:
> Hi,
> in include/linux/compiler-gcc.h :
>
> /* Optimization barrier */
> /* The "volatile" is due to gcc bugs */
> #define barrier() __asm__ __volatile__("": : :"memory")
>
> The comment of Linux says this is a gcc bug.But will any sane comp
31 matches
Mail list logo
