On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>> On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>>> On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>
>>>> Hi Uros,
>>>>
>>>> Can you take a look at my x86 backend changes so that they are ready
>>>> to check in once we have consensus.
>>>
>>> Please finish the talks about the correct approach first. Once the
>>> consensus is reached, please post the final version of the patches for
>>> review.
>>>
>>> BTW: I have no detailed insight in these issues, so I'll look mostly
>>> at the implementation details, probably early next week.
>>
>> One general remark is on the usage of -1 as an invalid register
>
> This has been rewritten. The checked in patch no longer does that.
Another issue:
+static void
+indirect_thunk_name (char name[32], int regno, bool need_bnd_p)
+{
+ if (USE_HIDDEN_LINKONCE)
+ {
+ const char *bnd = need_bnd_p ? "_bnd" : "";
+ if (regno >= 0)
+ {
+ const char *reg_prefix;
+ if (LEGACY_INT_REGNO_P (regno))
+ reg_prefix = TARGET_64BIT ? "r" : "e";
+ else
+ reg_prefix = "";
+ sprintf (name, "__x86_indirect_thunk%s_%s%s",
+ bnd, reg_prefix, reg_names[regno]);
+ }
+ else
+ sprintf (name, "__x86_indirect_thunk%s", bnd);
+ }
What is the benefit of reg_prefix? Can't we just live with e.g.:
__x86_indirect_thunk_ax
which is the true register name and is valid for 32bit and 64bit targets.
Uros.
