llvm dev - Feb 2018 - [X86] MoveImm flag for instructions

Hi,

I had (naively?) expected that the instruction to move immediate to
register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri,
MOV64ri32) would be marked with the flag MCID::MovImm via the
X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc).

I do not see that to be the case.

Can someone please tell me if my expectation is flawed? Is there a
better/different way to determine to test for move immediate to
register/memory instruction on X86 other that the existing interface
MCID::isMoveImmediate()?

Thanks,

Bharadwaj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/199e6a54/attachment.html>

That flag is specifically used by the foldImmediate optimization in the
Peephole pass. We don't implement the TLI foldImmediate hook the peephole
pass uses on x86 so we have no reason to set the flag on any instructions

What are you trying to do?

~Craig

On Fri, Feb 9, 2018 at 11:45 AM, S. Bharadwaj Yadavalli via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I had (naively?) expected that the instruction to move immediate to
> register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri,
> MOV64ri32) would be marked with the flag MCID::MovImm via the
> X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc).
>
> I do not see that to be the case.
>
> Can someone please tell me if my expectation is flawed? Is there a
> better/different way to determine to test for move immediate to
> register/memory instruction on X86 other that the existing interface
> MCID::isMoveImmediate()?
>
> Thanks,
>
> Bharadwaj
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/2209efec/attachment.html>

I am trying to categorize the machine instructions based on associated
static (i.e., as encoded in .td file) machine description and the
corresponding APIs.
I would like to perform appropriate actions based on the kind of
instruction in a tool that I am working on.

For example, I'd like to distinguish between memop instructions involving
immediate vs register. While it appears that I would be able to accomplish
this by rummaging through the instruction operands, a combination of the
flag(s) MayLoad/MayStore and MoveImm seemed attractive/clean/efficient(?),
if the instruction description did indeed use the flags.

Hence the question.

Thanks,

Bharadwaj

On Fri, Feb 9, 2018 at 12:17 PM, Craig Topper <craig.topper at gmail.com>
wrote:
> That flag is specifically used by the foldImmediate optimization in the
> Peephole pass. We don't implement the TLI foldImmediate hook the
peephole
> pass uses on x86 so we have no reason to set the flag on any instructions
>
> What are you trying to do?
>
> ~Craig
>
> On Fri, Feb 9, 2018 at 11:45 AM, S. Bharadwaj Yadavalli via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I had (naively?) expected that the instruction to move immediate to
>> register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri,
>> MOV64ri32) would be marked with the flag MCID::MovImm via the
>> X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc).
>>
>> I do not see that to be the case.
>>
>> Can someone please tell me if my expectation is flawed? Is there a
>> better/different way to determine to test for move immediate to
>> register/memory instruction on X86 other that the existing interface
>> MCID::isMoveImmediate()?
>>
>> Thanks,
>>
>> Bharadwaj
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/19572527/attachment.html>