[LLVMdev] Intrinsics __readeflags and __writeeflags

Reid Kleckner rnk at google.com
Tue Dec 17 11:00:29 PST 2013


I don't know enough about LLVM CodeGen to answer your questions.  I'm just
curious.

What is the intended level of support for these intrinsics?  Are they for
reading ALU flags like CF, OF, etc, or for seldom changed control flags
like TF and AC?  Even DF is typically scratch, and could be used for an -Oz
memmove lowering for example.

I don't think LLVM will ever really support capturing ALU flags from
previous ops without "using" the operation.  LLVM does have overflow
intrinsics though:
http://llvm.org/docs/LangRef.html#id1164


On Tue, Dec 17, 2013 at 1:02 AM, Alexey Volkov <avolkov.intel at gmail.com>wrote:

> Hello all,
>
> I am trying to implement intrinsics __readeflags and __writeeflags reading
> and writing EFLAGS register on x86.
> These intrinsics expand to two instructions popf and push to register for
> __readeflags and pushf and pop to register for __writeeflags.
> These instructions are not connected explicitly so I can't use patterns in
> .td file to match intrinsics.
>
> I tried to implement custom expansion making COPY DAG node with copy from
> EFLAGS to register.
> But this solution works only at -O0 level and failed at -O1 and higher:
> the problem is that Post-RA pseudo instruction expansion pass seems to be
> called only at -O0.
>
> Another way is to expand intrinsics to DAG nodes for each PUSH, POP, PUSHF
> and POPF instructions.
> This will add 4 new X86ISD types for DAG nodes for these instructions.
>
> What is the proper way to expand these intrinsics?
>
> --
> Alexey Volkov
> Intel Corporation
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131217/d47a6e7d/attachment.html>


More information about the llvm-dev mailing list