On Sat, May 7, 2011 at 7:07 PM, Xinliang David Li wrote:
> On Sat, May 7, 2011 at 5:46 AM, Richard Guenther
> wrote:
>> On Fri, May 6, 2011 at 7:57 PM, Xinliang David Li wrote:
> I want propose a more general solution.
>
> 1) Generic Annotation Support for gcc IR -- it is used attach
On Sat, May 7, 2011 at 5:46 AM, Richard Guenther
wrote:
> On Fri, May 6, 2011 at 7:57 PM, Xinliang David Li wrote:
I want propose a more general solution.
1) Generic Annotation Support for gcc IR -- it is used attach to
application/optimization specific annotation to gimple st
On Fri, May 6, 2011 at 7:57 PM, Xinliang David Li wrote:
>>> I want propose a more general solution.
>>>
>>> 1) Generic Annotation Support for gcc IR -- it is used attach to
>>> application/optimization specific annotation to gimple statements and
>>> annotations can be passed around across passes
>> I want propose a more general solution.
>>
>> 1) Generic Annotation Support for gcc IR -- it is used attach to
>> application/optimization specific annotation to gimple statements and
>> annotations can be passed around across passes. In gcc, I only see
>> HISTOGRAM annotation for value profilin
On Fri, May 6, 2011 at 04:55, Richard Guenther
wrote:
> On Thu, May 5, 2011 at 7:02 PM, Xinliang David Li wrote:
>>
>> 2) Support of CallInfo for each callsite. This is an annotation, but
>> more standardized. The callinfo can be used to record information such
>> as call attributes, call side ef
On Thu, May 5, 2011 at 7:02 PM, Xinliang David Li wrote:
> On Thu, May 5, 2011 at 2:16 AM, Richard Guenther
> wrote:
>> On Thu, May 5, 2011 at 12:19 AM, Xinliang David Li
>> wrote:
I can think of some more-or-less obvious high-level forms, one would
for example simply stick a new
On Thu, May 5, 2011 at 2:16 AM, Richard Guenther
wrote:
> On Thu, May 5, 2011 at 12:19 AM, Xinliang David Li wrote:
>>>
>>> I can think of some more-or-less obvious high-level forms, one would
>>> for example simply stick a new DISPATCH tree into gimple_call_fn
>>> (similar to how we can have OBJ
On Thu, May 5, 2011 at 12:19 AM, Xinliang David Li wrote:
>>
>> I can think of some more-or-less obvious high-level forms, one would
>> for example simply stick a new DISPATCH tree into gimple_call_fn
>> (similar to how we can have OBJ_TYPE_REF there), the DISPATCH
>> tree would be of variable len
>
> I can think of some more-or-less obvious high-level forms, one would
> for example simply stick a new DISPATCH tree into gimple_call_fn
> (similar to how we can have OBJ_TYPE_REF there), the DISPATCH
> tree would be of variable length, first operand the selector function
> and further operands
I submitted the patch.
Thanks,
-Sri.
On Wed, May 4, 2011 at 3:13 PM, Diego Novillo wrote:
> On Wed, May 4, 2011 at 15:35, Sriraman Tallam wrote:
>
>> * tree-pass.h (pass_tree_convert_builtin_dispatch): New pass.
>> (pass_ipa_multiversion_dispatch): New pass.
>> * builtin-ty
On Wed, May 4, 2011 at 15:35, Sriraman Tallam wrote:
> * tree-pass.h (pass_tree_convert_builtin_dispatch): New pass.
> (pass_ipa_multiversion_dispatch): New pass.
> * builtin-types.def (BT_PTR_FN_INT): New pointer type.
> (BT_FN_INT_PTR_FN_INT_PTR_PTR_VAR): New functio
On Tue, May 3, 2011 at 11:57 PM, Xinliang David Li wrote:
> On Tue, May 3, 2011 at 3:00 AM, Richard Guenther
> wrote:
>> On Tue, May 3, 2011 at 1:07 AM, Xinliang David Li wrote:
>>> On Mon, May 2, 2011 at 2:33 PM, Richard Guenther
>>> wrote:
On Mon, May 2, 2011 at 6:41 PM, Xinliang David L
On Tue, May 3, 2011 at 3:00 AM, Richard Guenther
wrote:
> On Tue, May 3, 2011 at 1:07 AM, Xinliang David Li wrote:
>> On Mon, May 2, 2011 at 2:33 PM, Richard Guenther
>> wrote:
>>> On Mon, May 2, 2011 at 6:41 PM, Xinliang David Li
>>> wrote:
On Mon, May 2, 2011 at 2:11 AM, Richard Guenthe
On May 3, 2011, at 8:34 AM, "Joseph S. Myers" wrote:.
> I don't think the forms in which some of the machine-specific built-in
> functions exist are particularly good for being available everywhere
I take it you've never just wanted something to compile, and hit one of these
yet. Let me know i
On Tue, 3 May 2011, Mike Stump wrote:
> And to go one step further, if we had this, we could use this to define
> all data manipulation machine built-ins as generic functions, available
> to all compiles as normal c code, so portable code could use them
> everywhere, and on platforms that had i
On May 3, 2011, at 3:07 AM, Richard Guenther wrote:
>>
>> There is no possibility for a high-level dispatch at the source level.
>> And if I'd have to design one I would use function overloading, like
>>
>> float compute_sth (float) __attribute__((version("sse4")))
>> {
>> ... sse4 code ...
>>
On Tue, May 3, 2011 at 12:00 PM, Richard Guenther
wrote:
3) it limits the lowering into one form which may not be ideal --
with builtin_dispatch, after hoisting optimization, the lowering can
use more efficient IFUNC scheme, for instance.
>>>
>>> I see no reason why we cannot trans
On Tue, May 3, 2011 at 1:07 AM, Xinliang David Li wrote:
> On Mon, May 2, 2011 at 2:33 PM, Richard Guenther
> wrote:
>> On Mon, May 2, 2011 at 6:41 PM, Xinliang David Li wrote:
>>> On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
>>> wrote:
On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David L
On Mon, May 2, 2011 at 2:33 PM, Richard Guenther
wrote:
> On Mon, May 2, 2011 at 6:41 PM, Xinliang David Li wrote:
>> On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
>> wrote:
>>> On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li
>>> wrote:
Here is the background for this feature:
On Mon, May 2, 2011 at 6:41 PM, Xinliang David Li wrote:
> On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
> wrote:
>> On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li
>> wrote:
>>> Here is the background for this feature:
>>>
>>> 1) People relies on function multi-version to explore hw feat
On Mon, May 2, 2011 at 1:44 PM, Eric Botcazou wrote:
>> Thanks. I committed this patch.
>>
>> -Sri.
>>
>> svn commit
>> Sending gcc/ChangeLog.google-main
>> Sending gcc/Makefile.in
>> Sending gcc/builtin-types.def
>> Sending gcc/builtins.def
>> Sending gcc/c-fami
> Thanks. I committed this patch.
>
> -Sri.
>
> svn commit
> Sendinggcc/ChangeLog.google-main
> Sendinggcc/Makefile.in
> Sendinggcc/builtin-types.def
> Sendinggcc/builtins.def
> Sendinggcc/c-family/c-common.c
> Sendinggcc/common.opt
> Sendingg
Thanks. I committed this patch.
-Sri.
svn commit
Sendinggcc/ChangeLog.google-main
Sendinggcc/Makefile.in
Sendinggcc/builtin-types.def
Sendinggcc/builtins.def
Sendinggcc/c-family/c-common.c
Sendinggcc/common.opt
Sendinggcc/doc/invoke.texi
Add
Ok. There may be more correctness related comments -- but those can be
addressed when available. For trunk, you need to address issues such
as multi-way dispatch.
Thanks,
David
On Mon, May 2, 2011 at 12:11 PM, Sriraman Tallam wrote:
> Hi,
>
> I want to submit this patch to google/main to make
Hi,
I want to submit this patch to google/main to make sure it is
available for our internal use at Google in order to materialize some
optimization opportunities. Let us continue this dicussion as I make
changes and submit this for review for trunk.
Thanks,
-Sri.
On Mon, May 2, 2011 at 9:41
On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
wrote:
> On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li wrote:
>> Here is the background for this feature:
>>
>> 1) People relies on function multi-version to explore hw features and
>> squeeze performance, but there is no standard ways of doin
On Fri, Apr 29, 2011 at 7:50 PM, Sriraman Tallam wrote:
>
> On Fri, Apr 29, 2011 at 1:56 AM, Richard Guenther
> wrote:
>>
>> On Fri, Apr 29, 2011 at 4:52 AM, Sriraman Tallam
>> wrote:
>> > I want this patch to be considered for google/main now. This is intended
>> > to be submitted to trunk for
On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li wrote:
> Here is the background for this feature:
>
> 1) People relies on function multi-version to explore hw features and
> squeeze performance, but there is no standard ways of doing so, either
> a) using indirect function calls with function p
Hi Richard,
Thanks for the comments. Please find inline responses.
On Fri, Apr 29, 2011 at 1:56 AM, Richard Guenther
wrote:
>
> On Fri, Apr 29, 2011 at 4:52 AM, Sriraman Tallam wrote:
> > I want this patch to be considered for google/main now. This is intended to
> > be submitted to trunk fo
Here is the background for this feature:
1) People relies on function multi-version to explore hw features and
squeeze performance, but there is no standard ways of doing so, either
a) using indirect function calls with function pointers set at program
initialization; b) using manual dispatch at e
On Fri, Apr 29, 2011 at 4:52 AM, Sriraman Tallam wrote:
> I want this patch to be considered for google/main now. This is intended to
> be submitted to trunk for review soon.
> This patch has been tested with crosstool bootstrap using buildit and by
> running all tests.
>
>
> Patch Description :
31 matches
Mail list logo
