Am Wed, 26 Nov 2014 17:19:25 +
schrieb "Iain Buclaw via D.gnu" :
> On 26 November 2014 at 15:40, Johannes Pfau via D.gnu
> wrote:
> > Has anybody had a closer look at cross-module inlining?
> > What exactly is necessary to get it working and how difficult
Am Wed, 26 Nov 2014 17:19:25 +
schrieb "Iain Buclaw via D.gnu" :
> On 26 November 2014 at 15:40, Johannes Pfau via D.gnu
> wrote:
> > Has anybody had a closer look at cross-module inlining?
> > What exactly is necessary to get it working and how difficult
On 26 November 2014 at 15:40, Johannes Pfau via D.gnu
wrote:
> Has anybody had a closer look at cross-module inlining?
> What exactly is necessary to get it working and how difficult would it
> be to implement?
>
> AFAICS
> * We'd need to do semantic3 on all imported module
Has anybody had a closer look at cross-module inlining?
What exactly is necessary to get it working and how difficult would it
be to implement?
AFAICS
* We'd need to do semantic3 on all imported modules
* We'd have to call (a modified) toObjfile on all functions from
imported module
On 10 January 2012 23:38, Artur Skawina wrote:
> On 01/11/12 00:30, Iain Buclaw wrote:
>> On 10 January 2012 19:49, Artur Skawina wrote:
I have porting the runtime/phobos asms to gcc asm on my to-do list, will
try to get to that within two weeks. What would be the preferred way -
v
On 01/11/12 00:30, Iain Buclaw wrote:
> On 10 January 2012 19:49, Artur Skawina wrote:
>>> I have porting the runtime/phobos asms to gcc asm on my to-do list, will
>>> try to get to that within two weeks. What would be the preferred way -
>>> version() guards? if yes - what version? Or would you p
On 10 January 2012 19:49, Artur Skawina wrote:
>> I have porting the runtime/phobos asms to gcc asm on my to-do list, will
>> try to get to that within two weeks. What would be the preferred way -
>> version() guards? if yes - what version? Or would you prefer replacing
>> the asms, if the changes
> I have porting the runtime/phobos asms to gcc asm on my to-do list, will
> try to get to that within two weeks. What would be the preferred way -
> version() guards? if yes - what version? Or would you prefer replacing
> the asms, if the changes are not going to be merged upstream anyway?
So i
== Quote from Mike Farnsworth (mike.farnswo...@gmail.com)'s article
> When doing -combine, is there a way to get gdc to feed all of the source to
> the
frontend all at once, such that all the definitions/bodies/etc. are all present
so
that inlining can occur? I would imagine even this strategy f
Trass3r Wrote:
> > // Assume __v4sf is defined by the compiler
> > pragma(set_attribute, _mm_add_ps, always_inline, artificial);
> > __v4sf _mm_add_ps (__v4sf __A, __v4sf __B)
> > {
> > return __builtin_ia32_addps(__A, __B);
> > }
>
> 2 notes:
> Isn't it pragma(GNU_set_attribute?
>
> And you
// Assume __v4sf is defined by the compiler
pragma(set_attribute, _mm_add_ps, always_inline, artificial);
__v4sf _mm_add_ps (__v4sf __A, __v4sf __B)
{
return __builtin_ia32_addps(__A, __B);
}
2 notes:
Isn't it pragma(GNU_set_attribute?
And you should be able to do
pragma(GNU_attribute, alwa
nd then never getting
inlined kinda defeats the purpose of the intrinsics. It'd be nice if we can
find a way to get cross-module inlining to work, even if it means using
link-time optimization.
-Mike
12 matches
Mail list logo
