On Fri, Nov 30, 2018 at 9:33 AM Alexander Monakov wrote:
>
> On Fri, 30 Nov 2018, Richard Biener wrote:
> > > Ping - as I think this approach addresses the root of the problem, I
> > > wouldn't
> > > like it to be forgotten.
> >
> > I agree this is also useful but it addresses another issue (that
On Fri, 30 Nov 2018, Richard Biener wrote:
> > Ping - as I think this approach addresses the root of the problem, I
> > wouldn't
> > like it to be forgotten.
>
> I agree this is also useful but it addresses another issue (that may appear to
> be related). asm inline is really a hint to the inlin
On Thu, Nov 29, 2018 at 5:44 PM Alexander Monakov wrote:
>
> > On Mon, 15 Oct 2018, Richard Biener wrote:
> > > I think it's sound but also note that I think it is logically independent
> > > of
> > > asm inline (). While it may work for the inlining issue for some kernel
> > > examples to asm i
> On Mon, 15 Oct 2018, Richard Biener wrote:
> > I think it's sound but also note that I think it is logically independent of
> > asm inline (). While it may work for the inlining issue for some kernel
> > examples to asm inline () is sth similar to always_inline for functions,
> > that is, even t
On Wed, Oct 31, 2018 at 06:39:31PM +0300, Alexander Monakov wrote:
> FWIW they went ahead and worked around the problem on their end via
> assembler macros
They have to anyway; they have to support GCC < 9 for a while. At the
very least until GCC 9 is released! ;-)
> (and Borislav's ping has go
On Mon, 15 Oct 2018, Richard Biener wrote:
> I think it's sound but also note that I think it is logically independent of
> asm inline (). While it may work for the inlining issue for some kernel
> examples to asm inline () is sth similar to always_inline for functions,
> that is, even though an a
On Mon, Oct 15, 2018 at 10:45:08PM +0300, Alexander Monakov wrote:
> On Mon, 15 Oct 2018, Segher Boessenkool wrote:
> > On Sun, Oct 14, 2018 at 11:07:20PM +0300, Alexander Monakov wrote:
> > > For Basic asms, no similar mechanism is necessary since they are
> > > antithetical
> > > to efficiency i
On Mon, 15 Oct 2018, Segher Boessenkool wrote:
> On Sun, Oct 14, 2018 at 11:07:20PM +0300, Alexander Monakov wrote:
> > For Basic asms, no similar mechanism is necessary since they are
> > antithetical
> > to efficiency in the first place.
>
> I missed this part.
>
> asm("bla");
>
> means alm
On Sun, Oct 14, 2018 at 11:07:20PM +0300, Alexander Monakov wrote:
> For Basic asms, no similar mechanism is necessary since they are antithetical
> to efficiency in the first place.
I missed this part.
asm("bla");
means almost the same as
asm("bla" : );
and there is nothing in there that
On Sun, Oct 14, 2018 at 11:07:20PM +0300, Alexander Monakov wrote:
> impacts inlining decisions badly, since GCC assumes cost of the asm to be
> high, even though it emits just one instruction to the text section. I'd
> like to point out that branch range optimization is also negatively affected.
> > I think only double quote, backslash, backtick remain unclaimed. And of
> > course
> > ASCII \0 through \040 and \177 ;)
>
> I see. Apart from using some of the traditional begin-end sequences we
> could use %; or similar on each line to "comment" it?
I guess in theory we could define perce
On Mon, Oct 15, 2018 at 12:36 PM Alexander Monakov wrote:
>
> On Mon, 15 Oct 2018, Richard Biener wrote:
> >
> > Oh, and I personally find %` ugly ;) What non-alnum chars
> > are taken by backends?
>
> I think only double quote, backslash, backtick remain unclaimed. And of course
> ASCII \0 throu
Jakub Jelinek writes:
> On Mon, Oct 15, 2018 at 01:53:09PM +0300, Alexander Monakov wrote:
>> On Mon, 15 Oct 2018, Jakub Jelinek wrote:
>>
>> > On Mon, Oct 15, 2018 at 01:36:36PM +0300, Alexander Monakov wrote:
>> > > On Mon, 15 Oct 2018, Richard Biener wrote:
>> > > >
>> > > > Oh, and I person
On Mon, Oct 15, 2018 at 01:53:09PM +0300, Alexander Monakov wrote:
> On Mon, 15 Oct 2018, Jakub Jelinek wrote:
>
> > On Mon, Oct 15, 2018 at 01:36:36PM +0300, Alexander Monakov wrote:
> > > On Mon, 15 Oct 2018, Richard Biener wrote:
> > > >
> > > > Oh, and I personally find %` ugly ;) What non-a
On Mon, 15 Oct 2018, Jakub Jelinek wrote:
> On Mon, Oct 15, 2018 at 01:36:36PM +0300, Alexander Monakov wrote:
> > On Mon, 15 Oct 2018, Richard Biener wrote:
> > >
> > > Oh, and I personally find %` ugly ;) What non-alnum chars
> > > are taken by backends?
> >
> > I think only double quote, bac
On Mon, Oct 15, 2018 at 01:36:36PM +0300, Alexander Monakov wrote:
> On Mon, 15 Oct 2018, Richard Biener wrote:
> >
> > Oh, and I personally find %` ugly ;) What non-alnum chars
> > are taken by backends?
>
> I think only double quote, backslash, backtick remain unclaimed. And of course
> ASCII
On Mon, 15 Oct 2018, Richard Biener wrote:
>
> Oh, and I personally find %` ugly ;) What non-alnum chars
> are taken by backends?
I think only double quote, backslash, backtick remain unclaimed. And of course
ASCII \0 through \040 and \177 ;)
Alexander
On Sun, Oct 14, 2018 at 10:07 PM Alexander Monakov wrote:
>
> Hello,
>
> This is an alternative proposal to the "asm inline" feature.
>
> Kernel developers have reported suboptimal optimization where use of asm
> statements such as
>
> asm("ud2\n"
> ".pushsection foo\n"
> ...
>
Hello,
This is an alternative proposal to the "asm inline" feature.
Kernel developers have reported suboptimal optimization where use of asm
statements such as
asm("ud2\n"
".pushsection foo\n"
...
".popsection\n" : : ...)
impacts inlining decisions badly, since GCC assumes c
19 matches
Mail list logo
