On Mon, Jun 17, 2013 at 10:49 AM, Sriraman Tallam wrote:
> On Fri, Jun 14, 2013 at 11:08 AM, Sriraman Tallam wrote:
>> On Fri, Jun 14, 2013 at 1:43 AM, Richard Biener
>> wrote:
>>> On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam
>>> wrote:
On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka w
On Fri, Jun 14, 2013 at 11:08 AM, Sriraman Tallam wrote:
> On Fri, Jun 14, 2013 at 1:43 AM, Richard Biener
> wrote:
>> On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam wrote:
>>> On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka wrote:
> * tree-inline.c (expand_call_inline): Allow the err
On Fri, Jun 14, 2013 at 1:43 AM, Richard Biener
wrote:
> On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam wrote:
>> On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka wrote:
* tree-inline.c (expand_call_inline): Allow the error to be flagged
in early inline pass.
* ip
On Fri, Jun 14, 2013 at 10:43:34AM +0200, Richard Biener wrote:
> On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam wrote:
> > On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka wrote:
> >>> * tree-inline.c (expand_call_inline): Allow the error to be flagged
> >>> in early inline pass.
> >>
> On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam wrote:
> > On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka wrote:
> >>> * tree-inline.c (expand_call_inline): Allow the error to be flagged
> >>> in early inline pass.
> >>> * ipa-inline.c (inline_always_inline_functions): Pretend
On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam wrote:
> On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka wrote:
>>> * tree-inline.c (expand_call_inline): Allow the error to be flagged
>>> in early inline pass.
>>> * ipa-inline.c (inline_always_inline_functions): Pretend always_in
On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka wrote:
>> * tree-inline.c (expand_call_inline): Allow the error to be flagged
>> in early inline pass.
>> * ipa-inline.c (inline_always_inline_functions): Pretend always_inline
>> functions are inlined during failures to flag an
yes, what you said makes sense.
thanks,
David
On Thu, Jun 13, 2013 at 12:45 PM, Jan Hubicka wrote:
>> If you want to flag errors for all possible wrongly used always_inline
>> attribute, should this change be done in can_inline_edge_p? Or keep
>> your current change, but also add a warning (som
> If you want to flag errors for all possible wrongly used always_inline
> attribute, should this change be done in can_inline_edge_p? Or keep
> your current change, but also add a warning (something like 'always
> inline function is ignored etc') in inline_always_inline_functions
> when inline tra
> * tree-inline.c (expand_call_inline): Allow the error to be flagged
> in early inline pass.
> * ipa-inline.c (inline_always_inline_functions): Pretend always_inline
> functions are inlined during failures to flag an error.
> * gcc.target/i386/inline_error.c: New test
If you want to flag errors for all possible wrongly used always_inline
attribute, should this change be done in can_inline_edge_p? Or keep
your current change, but also add a warning (something like 'always
inline function is ignored etc') in inline_always_inline_functions
when inline transformatio
On Thu, Jun 13, 2013 at 10:19 AM, Jan Hubicka wrote:
>> On Thu, Jun 13, 2013 at 10:07 AM, Jan Hubicka wrote:
>> >> Can you create a helper function to flag the error and perhaps also
>> >> put that check inside can_inline_edge_p ?
>> >>
>> >> David
>> >>
>> >>
>> >> On Wed, Jun 12, 2013 at 6:00 P
> On Thu, Jun 13, 2013 at 10:07 AM, Jan Hubicka wrote:
> >> Can you create a helper function to flag the error and perhaps also
> >> put that check inside can_inline_edge_p ?
> >>
> >> David
> >>
> >>
> >> On Wed, Jun 12, 2013 at 6:00 PM, Sriraman Tallam
> >> wrote:
> >> > Hi Honza,
> >> >
> >>
On Thu, Jun 13, 2013 at 10:07 AM, Jan Hubicka wrote:
>> Can you create a helper function to flag the error and perhaps also
>> put that check inside can_inline_edge_p ?
>>
>> David
>>
>>
>> On Wed, Jun 12, 2013 at 6:00 PM, Sriraman Tallam wrote:
>> > Hi Honza,
>> >
>> >I have isolated the ipa
> Can you create a helper function to flag the error and perhaps also
> put that check inside can_inline_edge_p ?
>
> David
>
>
> On Wed, Jun 12, 2013 at 6:00 PM, Sriraman Tallam wrote:
> > Hi Honza,
> >
> >I have isolated the ipa-inline.c part into a separate patch with a
> > test and atta
Can you create a helper function to flag the error and perhaps also
put that check inside can_inline_edge_p ?
David
On Wed, Jun 12, 2013 at 6:00 PM, Sriraman Tallam wrote:
> Hi Honza,
>
>I have isolated the ipa-inline.c part into a separate patch with a
> test and attached it here. The patc
Hi Honza,
I have isolated the ipa-inline.c part into a separate patch with a
test and attached it here. The patch is simple. Could you please take
a look?
* ipa-inline.c (can_early_inline_edge_p): Flag an error when
the function that cannot be inlined is target specific.
Ping.
On Tue, Jun 4, 2013 at 2:41 PM, Sriraman Tallam wrote:
> Ping.
>
> On Thu, May 23, 2013 at 2:41 PM, Sriraman Tallam wrote:
>> Ping, for review of ipa-inline.c change.
>>
>> Sri
>>
>> On Mon, May 20, 2013 at 11:04 AM, Sriraman Tallam
>> wrote:
>>> On Fri, May 17, 2013 at 11:21 PM, Jakub J
Ping.
On Thu, May 23, 2013 at 2:41 PM, Sriraman Tallam wrote:
> Ping, for review of ipa-inline.c change.
>
> Sri
>
> On Mon, May 20, 2013 at 11:04 AM, Sriraman Tallam wrote:
>> On Fri, May 17, 2013 at 11:21 PM, Jakub Jelinek wrote:
>>> On Fri, May 17, 2013 at 09:00:21PM -0700, Sriraman Tallam w
Ping, for review of ipa-inline.c change.
Sri
On Mon, May 20, 2013 at 11:04 AM, Sriraman Tallam wrote:
> On Fri, May 17, 2013 at 11:21 PM, Jakub Jelinek wrote:
>> On Fri, May 17, 2013 at 09:00:21PM -0700, Sriraman Tallam wrote:
>>> --- ipa-inline.c (revision 198950)
>>> +++ ipa-inline.c
On Fri, May 17, 2013 at 11:21 PM, Jakub Jelinek wrote:
> On Fri, May 17, 2013 at 09:00:21PM -0700, Sriraman Tallam wrote:
>> --- ipa-inline.c (revision 198950)
>> +++ ipa-inline.c (working copy)
>> @@ -374,7 +374,33 @@ can_early_inline_edge_p (struct cgraph_edge *e)
>>return fals
On Sat, May 18, 2013 at 6:00 AM, Sriraman Tallam wrote:
>>> > I don't really understand why you made the change to x86intrin.h instead
>>> > of
>>> > making it inside each *mmintrin.h header. The code would be the same size,
>>> > it would let us include smmintrin.h directly if we wanted to, and
On Fri, May 17, 2013 at 09:00:21PM -0700, Sriraman Tallam wrote:
> --- ipa-inline.c (revision 198950)
> +++ ipa-inline.c (working copy)
> @@ -374,7 +374,33 @@ can_early_inline_edge_p (struct cgraph_edge *e)
>return false;
> }
>if (!can_inline_edge_p (e, true))
> -retu
On Thu, May 16, 2013 at 04:00:53PM -0700, Sriraman Tallam wrote:
> On Thu, May 16, 2013 at 3:55 PM, Marc Glisse wrote:
> > I don't really understand why you made the change to x86intrin.h instead of
> > making it inside each *mmintrin.h header. The code would be the same size,
> > it would let us
On Thu, May 16, 2013 at 3:55 PM, Marc Glisse wrote:
> On Thu, 16 May 2013, Sriraman Tallam wrote:
>
>> Hi Jakub,
>>
>> I have taken your proposed changes and made patch for this. Please
>> let me know what you think. I have changed only the headers mmintrin.h
>> and x86intrin.h as that includes
On Thu, 16 May 2013, Sriraman Tallam wrote:
Hi Jakub,
I have taken your proposed changes and made patch for this. Please
let me know what you think. I have changed only the headers mmintrin.h
and x86intrin.h as that includes all the other headers.
I don't really understand why you made the
Hi Jakub,
I have taken your proposed changes and made patch for this. Please
let me know what you think. I have changed only the headers mmintrin.h
and x86intrin.h as that includes all the other headers. The builtins
get enabled automatically when the pragma target is specified so need
to do
On Tue, May 14, 2013 at 3:04 AM, Jakub Jelinek wrote:
> On Tue, May 14, 2013 at 10:39:13AM +0200, Jakub Jelinek wrote:
>> When trying with -O2 -mno-avx:
>> #ifndef __AVX__
>> #pragma GCC push_options
>> #pragma GCC target("avx")
>> #define __DISABLE_AVX__
>> #endif
>> typedef float __v8sf __attrib
On Tue, May 14, 2013 at 12:22:05PM +0200, Richard Biener wrote:
> > The problem is that in the first testcase, the VAR_DECL c (guess also b and
> > a) have TYPE_MODE (TREE_TYPE (c)) == V8SFmode (this is dynamic, for vector
> > types TYPE_MODE is a function call), but DECL_MODE (c) is BLKmode
> > (i
On Tue, May 14, 2013 at 12:04 PM, Jakub Jelinek wrote:
> On Tue, May 14, 2013 at 10:39:13AM +0200, Jakub Jelinek wrote:
>> When trying with -O2 -mno-avx:
>> #ifndef __AVX__
>> #pragma GCC push_options
>> #pragma GCC target("avx")
>> #define __DISABLE_AVX__
>> #endif
>> typedef float __v8sf __attri
On Tue, May 14, 2013 at 10:39:13AM +0200, Jakub Jelinek wrote:
> When trying with -O2 -mno-avx:
> #ifndef __AVX__
> #pragma GCC push_options
> #pragma GCC target("avx")
> #define __DISABLE_AVX__
> #endif
> typedef float __v8sf __attribute__ ((__vector_size__ (32)));
> typedef float __m256 __attribu
On Tue, May 14, 2013 at 10:39 AM, Jakub Jelinek wrote:
> On Tue, May 14, 2013 at 08:58:55AM +0200, Uros Bizjak wrote:
>> I think that the option should be named -mtarget-builtins.
>
> There shouldn't be an option for it at all. If constructing the builtins is
> slow (it is), we should just create
On Tue, May 14, 2013 at 08:58:55AM +0200, Uros Bizjak wrote:
> I think that the option should be named -mtarget-builtins.
There shouldn't be an option for it at all. If constructing the builtins is
slow (it is), we should just create them lazily, the
*builtin_decl_{explicit,implicit}* APIs were a
On Mon, May 13, 2013 at 11:46 PM, H.J. Lu wrote:
> On Mon, Apr 29, 2013 at 10:47 AM, Sriraman Tallam
> wrote:
>> On Thu, Apr 25, 2013 at 12:41 PM, Joseph S. Myers
>> wrote:
>>> On Tue, 16 Apr 2013, Sriraman Tallam wrote:
>>>
Ok, it is on by default now. There
On Mon, May 13, 2013 at 2:21 PM, Sriraman Tallam wrote:
> Ping.
>
> On Thu, May 9, 2013 at 2:20 PM, Sriraman Tallam wrote:
>> cc:Diego
>>
>> On Tue, May 7, 2013 at 2:41 PM, Sriraman Tallam wrote:
>>> Ping.
>>>
>>> On Thu, May 2, 2013 at 3:51 PM, Sriraman Tallam wrote:
Ping.
On Mo
Ping.
On Thu, May 9, 2013 at 2:20 PM, Sriraman Tallam wrote:
> cc:Diego
>
> On Tue, May 7, 2013 at 2:41 PM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Thu, May 2, 2013 at 3:51 PM, Sriraman Tallam wrote:
>>> Ping.
>>>
>>> On Mon, Apr 29, 2013 at 10:47 AM, Sriraman Tallam
>>> wrote:
On Thu,
cc:Diego
On Tue, May 7, 2013 at 2:41 PM, Sriraman Tallam wrote:
> Ping.
>
> On Thu, May 2, 2013 at 3:51 PM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Mon, Apr 29, 2013 at 10:47 AM, Sriraman Tallam
>> wrote:
>>> On Thu, Apr 25, 2013 at 12:41 PM, Joseph S. Myers
>>> wrote:
On Tue, 16 Apr 20
Ping.
On Thu, May 2, 2013 at 3:51 PM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, Apr 29, 2013 at 10:47 AM, Sriraman Tallam wrote:
>> On Thu, Apr 25, 2013 at 12:41 PM, Joseph S. Myers
>> wrote:
>>> On Tue, 16 Apr 2013, Sriraman Tallam wrote:
>>>
Ok, it is on by default now. There is a way
Ping.
On Mon, Apr 29, 2013 at 10:47 AM, Sriraman Tallam wrote:
> On Thu, Apr 25, 2013 at 12:41 PM, Joseph S. Myers
> wrote:
>> On Tue, 16 Apr 2013, Sriraman Tallam wrote:
>>
>>> Ok, it is on by default now. There is a way to turn it off, with
>>> -mno-generate-builtins.
>>
>> Any new option nee
On Thu, Apr 25, 2013 at 12:41 PM, Joseph S. Myers
wrote:
> On Tue, 16 Apr 2013, Sriraman Tallam wrote:
>
>> Ok, it is on by default now. There is a way to turn it off, with
>> -mno-generate-builtins.
>
> Any new option needs documenting in invoke.texi.
Added and new patch attached.
Thanks
Sri
On Tue, 16 Apr 2013, Sriraman Tallam wrote:
> Ok, it is on by default now. There is a way to turn it off, with
> -mno-generate-builtins.
Any new option needs documenting in invoke.texi.
--
Joseph S. Myers
jos...@codesourcery.com
Ping.
On Wed, Apr 17, 2013 at 7:13 PM, Sriraman Tallam wrote:
> +HJ
>
> On Tue, Apr 16, 2013 at 1:54 PM, Sriraman Tallam wrote:
>> Hi,
>>
>> I have attached an updated patch that addresses all the comments raised.
>>
>> On Fri, Apr 12, 2013 at 1:58 AM, Jakub Jelinek wrote:
>>> On Thu, Apr 11,
+HJ
On Tue, Apr 16, 2013 at 1:54 PM, Sriraman Tallam wrote:
> Hi,
>
> I have attached an updated patch that addresses all the comments raised.
>
> On Fri, Apr 12, 2013 at 1:58 AM, Jakub Jelinek wrote:
>> On Thu, Apr 11, 2013 at 12:05:41PM -0700, Sriraman Tallam wrote:
>>> I have attached a patc
Hi,
I have attached an updated patch that addresses all the comments raised.
On Fri, Apr 12, 2013 at 1:58 AM, Jakub Jelinek wrote:
> On Thu, Apr 11, 2013 at 12:05:41PM -0700, Sriraman Tallam wrote:
>> I have attached a patch that fixes this. I have added an option
>> "-mgenerate-builtins" that
On Fri, Apr 12, 2013 at 1:58 AM, Jakub Jelinek wrote:
> On Thu, Apr 11, 2013 at 12:05:41PM -0700, Sriraman Tallam wrote:
>> I have attached a patch that fixes this. I have added an option
>> "-mgenerate-builtins" that will do two things. It will define a macro
>> "__ALL_ISA__" which will expose t
On Fri, Apr 12, 2013 at 1:22 AM, Richard Biener
wrote:
> On Thu, Apr 11, 2013 at 10:18 PM, Xinliang David Li
> wrote:
>> Great that it is already covered.
>
> I expect that with more convoluted code you'll ICE eventually.
Yes, those are bugs that need to be fixed.
> There is also
> a bugreport
On Thu, Apr 11, 2013 at 12:05:41PM -0700, Sriraman Tallam wrote:
> I have attached a patch that fixes this. I have added an option
> "-mgenerate-builtins" that will do two things. It will define a macro
> "__ALL_ISA__" which will expose the *intrin.h functions. It will also
> expose all the target
On Thu, Apr 11, 2013 at 10:18 PM, Xinliang David Li wrote:
> Great that it is already covered.
I expect that with more convoluted code you'll ICE eventually. There is also
a bugreport about exactly this issue which should be referenced when a fix
is committed.
Oh, and target maintainers disagre
Great that it is already covered.
David
On Thu, Apr 11, 2013 at 1:09 PM, Sriraman Tallam wrote:
> On Thu, Apr 11, 2013 at 1:05 PM, Sriraman Tallam wrote:
>> On Thu, Apr 11, 2013 at 12:43 PM, Xinliang David Li
>> wrote:
>>> What is the compile time impact for turning it on? Code not including
On Thu, Apr 11, 2013 at 1:05 PM, Sriraman Tallam wrote:
> On Thu, Apr 11, 2013 at 12:43 PM, Xinliang David Li
> wrote:
>> What is the compile time impact for turning it on? Code not including
>> the intrinsic headers should not be affected too much. If the impact
>> is small, why not turning on
On Thu, Apr 11, 2013 at 12:43 PM, Xinliang David Li wrote:
> What is the compile time impact for turning it on? Code not including
> the intrinsic headers should not be affected too much. If the impact
> is small, why not turning on this option by default -- which seems to
> be the behavior of IC
What is the compile time impact for turning it on? Code not including
the intrinsic headers should not be affected too much. If the impact
is small, why not turning on this option by default -- which seems to
be the behavior of ICC.
With this option, all functions without the appropriate target o
Hi,
*mmintrin headers does not work with function specific opts.
Example 1:
#include
__attribute__((target("sse4.1")))
__m128i foo(__m128i *V)
{
return _mm_stream_load_si128(V);
}
$ g++ test.cc
smmintrin.h:31:3: error: #error "SSE4.1 instruction set not enabled"
# error "SSE4.1 ins
53 matches
Mail list logo
