On 2012-08-28 01:13, Chung-Lin Tang wrote:
> + icode = optab_handler (get_thread_pointer_optab, Pmode);
Until we decide there's no point in the distinction, this should
be spelled direct_optab_handler, to match OPTAB_D with which the
optab is declared.
Otherwise ok.
r~
On 12/7/12 2:52 PM, Chung-Lin Tang wrote:
> Core parts adding the new hooks. BUILT_IN_THREAD_POINTER and
> BUILT_IN_SET_THREAD_POINTER are different hooks, as some targets only
> implement one of them (thread pointer read).
Following Richard H.'s advice, I have revised the patch to use a
standard
On 07/11/2012 11:52 PM, Chung-Lin Tang wrote:
> * target.def (expand_builtin_thread_pointer): New target hook.
> (expand_builtin_set_thread_pointer): New target hook.
Is there a particular reason why you're using target hooks rather than
named patterns in the md file? This *is* ha
On 12/7/14 9:58 AM, Mike Stump wrote:
> On Jul 12, 2012, at 11:47 PM, Chung-Lin Tang wrote:
>>> and then for the return value, maybe a const0_rtx for Pmode.
>>
>> A little unsure what you mean. Are you referring to return const0_rtx
>> for default_expand_builtin_thread_pointer() instead of NULL?
On Jul 12, 2012, at 11:47 PM, Chung-Lin Tang wrote:
>> and then for the return value, maybe a const0_rtx for Pmode.
>
> A little unsure what you mean. Are you referring to return const0_rtx
> for default_expand_builtin_thread_pointer() instead of NULL?
Yes. NULL has the habit of crashing thing
Richard Sandiford writes:
> Function names should be quoted by %< %>. But maybe we can save the
> translators some work and use:
>
> sorry ("%qs is not available for this target",
> "__builtin_thread_pointer()");
> ...
> sorry ("%qs is not available for this target",
> "__builtin_s
On 2012/7/13 02:37 AM, Richard Sandiford wrote:
>> +void
>> > +default_expand_builtin_set_thread_pointer (rtx val ATTRIBUTE_UNUSED)
>> > +{
>> > + sorry ("__builtin_set_thread_pointer() not available for this target");
>> > +}
> Function names should be quoted by %< %>. But maybe we can save the
On 2012/7/13 09:28 AM, Mike Stump wrote:
> On Jul 11, 2012, at 11:52 PM, Chung-Lin Tang wrote:
>> Core parts adding the new hooks. BUILT_IN_THREAD_POINTER and
>> BUILT_IN_SET_THREAD_POINTER are different hooks, as some targets only
>> implement one of them (thread pointer read).
>
> sorry seems a
On Jul 11, 2012, at 11:52 PM, Chung-Lin Tang wrote:
> Core parts adding the new hooks. BUILT_IN_THREAD_POINTER and
> BUILT_IN_SET_THREAD_POINTER are different hooks, as some targets only
> implement one of them (thread pointer read).
sorry seems a little overly dramatic. I would have thought that
Hi Chung-Lin,
Chung-Lin Tang writes:
> Core parts adding the new hooks. BUILT_IN_THREAD_POINTER and
> BUILT_IN_SET_THREAD_POINTER are different hooks, as some targets only
> implement one of them (thread pointer read).
Thanks a lot for doing this. It looks great to me, although I can't
approve
Core parts adding the new hooks. BUILT_IN_THREAD_POINTER and
BUILT_IN_SET_THREAD_POINTER are different hooks, as some targets only
implement one of them (thread pointer read).
Thanks,
Chung-Lin
* targhooks.c (default_expand_builtin_thread_pointer): New.
(default_expand_builtin_set
11 matches
Mail list logo
