Convert Smi to Operand.Immediate in ARM64 backend?

[Thomson Tan]

The ARM64 backend could convert Smi to Operand by assigning tagged Smi to immediate filed in Operand class, as below code snippet. Then the immediate field is tagged Smi value, would it cause problem when encoding this operand?

// src\arm64\assember-arm64-inl.h

template<>

struct ImmediateInitializer<Smi*> {

…

  static inline int64_t immediate_for(Smi* t) {;

    return reinterpret_cast<int64_t>(t);

  }

};

[Ben Noordhuis]

On Sat, Apr 21, 2018 at 2:58 AM, Thomson Tan <lil...@gmail.com> wrote:
> The ARM64 backend could convert Smi to Operand by assigning tagged Smi to
> immediate filed in Operand class, as below code snippet. Then the immediate
> field is tagged Smi value, would it cause problem when encoding this
> operand?
>
> // src\arm64\assember-arm64-inl.h
> template<>
> struct ImmediateInitializer<Smi*> {

> static const bool kIsIntType = false;
> static inline RelocInfo::Mode rmode_for(Smi* t) { return RelocInfo::NONE;

> }
> static inline int64_t immediate_for(Smi* t) {;
> return reinterpret_cast<int64_t>(t);
> }
> };

No, If I understand your question correctly.

Smis are not heap objects and don't need additional bookkeeping.
That's unlike embedded object pointers, those need to be made visible
to the garbage collector.

[Thomson Tan]

Thanks. I meant whether Smi should be untagged to the real int value (without tag) when assigning to Operand immediate field. 

[Ben Noordhuis]

On Sun, Apr 22, 2018 at 7:49 AM, Thomson Tan <lil...@gmail.com> wrote:
> Thanks. I meant whether Smi should be untagged to the real int value
> (without tag) when assigning to Operand immediate field.

Ah, like that. No, most of the time you don't need to untag. Smi +
Smi = Smi (barring overflow.)