Hello,
In discussion of proposed fix for PR 44281 Michael said:
[ https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01963.html ]
> [...] What I mean to say is, the following is currently proper use of
> global reg vars:
>
>
> register uint64_t ugh __asm__("rbx"); //r11, whatever
> void write_in
Hi,
On Mon, 23 Apr 2018, Alexander Monakov wrote:
> In discussion of proposed fix for PR 44281 Michael said:
> [ https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01963.html ]
> > [...] What I mean to say is, the following is currently proper use of
> > global reg vars:
> >
> >
> > register ui
On Mon, 23 Apr 2018, Michael Matz wrote:
> In your follow-up patches you actually change the very documentation that
> makes the above valid and supported ...
I don't see how a user reading the documentation could infer that asms and
global reg vars interact like you say. I am particularly unsure
Hi,
On Mon, 23 Apr 2018, Alexander Monakov wrote:
> I don't see how a user reading the documentation could infer that asms
> and global reg vars interact like you say.
That was always my interpretation of this clause (old docu, the current
bullet list seems to have removed some clarity) and me
On Mon, 23 Apr 2018, Michael Matz wrote:
> Sooo, hmm, I don't know ;-) We could try doing a roll backwards and
> demand explicit dependencies from asms with unknown effects on the few
> unknown users, though the timing really makes me nervous. But my gut
> feeling says to remain (or become aga
Hi,
On Tue, 24 Apr 2018, Alexander Monakov wrote:
> On Mon, 23 Apr 2018, Michael Matz wrote:
> > Sooo, hmm, I don't know ;-) We could try doing a roll backwards and
> > demand explicit dependencies from asms with unknown effects on the few
> > unknown users, though the timing really makes me n
On Tue, 24 Apr 2018, Michael Matz wrote:
> Sure but even for that we need to decide if we want to go that or the
> opposite way, and that's not easy when a deadline is lurking behind you.
I am surprised there is any question. Even gcc-3.4 optimizes reg vars over asms,
on a testcase not unlike the
Hi,
On Tue, 24 Apr 2018, Alexander Monakov wrote:
> > Sure but even for that we need to decide if we want to go that or the
> > opposite way, and that's not easy when a deadline is lurking behind
> > you.
>
> I am surprised there is any question. Even gcc-3.4 optimizes reg vars
> over asms, o
On Tue, 24 Apr 2018, Michael Matz wrote:
> Well, documentation is both: a description and specification. If we
> change the documentation now we might not be in the position anymore to
> change behaviour and docu back because people might in the meanwhile rely
> on the specification. Which is
Hi,
On Tue, 24 Apr 2018, Alexander Monakov wrote:
> On Tue, 24 Apr 2018, Michael Matz wrote:
> > Well, documentation is both: a description and specification. If we
> > change the documentation now we might not be in the position anymore to
> > change behaviour and docu back because people mig
On Tue, 24 Apr 2018, Michael Matz wrote:
> What is lost here (it wasn't explicit before, but is the case and must
> continue to work) is that function calls and returns count as needing the
> observable value in the specified register (function calls also count as
> setters of them). I think th
Hi,
On Tue, 24 Apr 2018, Alexander Monakov wrote:
> On Tue, 24 Apr 2018, Michael Matz wrote:
> > What is lost here (it wasn't explicit before, but is the case and must
> > continue to work) is that function calls and returns count as needing the
> > observable value in the specified register (f
On 04/24/2018 07:21 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 24 Apr 2018, Alexander Monakov wrote:
>
>>> Sure but even for that we need to decide if we want to go that or the
>>> opposite way, and that's not easy when a deadline is lurking behind
>>> you.
>>
>> I am surprised there is any ques
Hi,
On Tue, 1 May 2018, Jeff Law wrote:
> The very nature of a traditional asm implies that it can read or write
> anything visible to compiler. We can't realistically peek inside to see
> what's happening and the user hasn't provided appropriate dataflow
> information. One could make the ar
On 05/02/2018 07:45 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 1 May 2018, Jeff Law wrote:
>
>> The very nature of a traditional asm implies that it can read or write
>> anything visible to compiler. We can't realistically peek inside to see
>> what's happening and the user hasn't provided appr
On Tue, 1 May 2018, Jeff Law wrote:
> The very nature of a traditional asm implies that it can read or write
> anything visible to compiler.
No? Basic asms are not allowed to read/write general purpose registers,
the stack pointer, the instruction pointer. I think they are considered
to be wild me
16 matches
Mail list logo
