[LLVMdev] MC X86 lacking support for hyphenated VIA Padlock instructions

Brad Smith brad at comstyle.com
Mon Jan 21 18:32:59 PST 2013


On Thu, Jan 17, 2013 at 04:19:01AM -0500, Brad Smith wrote:
> On Wed, Jan 16, 2013 at 12:04:52PM -0500, Stephen Checkoway wrote:
> > 
> > On Jan 16, 2013, at 10:07 AM, Brad Smith <brad at comstyle.com> wrote:
> > 
> > > I was wondering if someone with more familiarity with MC
> > > on X86 could consider looking into adding support for
> > > the hyphenated versions of the VIA Padlock instructions?
> > 
> > 
> > Take a look at llvm/lib/Target/X86InstrSystem.td perhaps.
> 
> I had already found that, but I wouldn't be asking if it was
> that straightforward.
> 
> I thought I would try something like the following..
> 
> Index: lib/Target/X86/X86InstrSystem.td
> ===================================================================
> --- lib/Target/X86/X86InstrSystem.td	(revision 161828)
> +++ lib/Target/X86/X86InstrSystem.td	(working copy)
> @@ -445,6 +445,7 @@
>    def XSTORE : I<0xc0, RawFrm, (outs), (ins), "xstore", []>, A7;
>  
>  def : InstAlias<"xstorerng", (XSTORE)>;
> +def : InstAlias<"xstore-rng", (XSTORE)>;
>  
>  let Defs = [RSI, RDI], Uses = [RBX, RDX, RSI, RDI] in {
>    def XCRYPTECB : I<0xc8, RawFrm, (outs), (ins), "xcryptecb", []>, A7;
> @@ -454,6 +455,12 @@
>    def XCRYPTOFB : I<0xe8, RawFrm, (outs), (ins), "xcryptofb", []>, A7;
>  }
>  
> +def : InstAlias<"xcrypt-ecb", (XCRYPTECB)>;
> +def : InstAlias<"xcrypt-cbc", (XCRYPTCBC)>;
> +def : InstAlias<"xcrypt-ctr", (XCRYPTCTR)>;
> +def : InstAlias<"xcrypt-cfb", (XCRYPTCFB)>;
> +def : InstAlias<"xcrypt-ofb", (XCRYPTOFB)>;
> +
>  let Defs = [RAX, RSI, RDI], Uses = [RAX, RSI, RDI] in {
>    def XSHA1 : I<0xc8, RawFrm, (outs), (ins), "xsha1", []>, A6;
>    def XSHA256 : I<0xd0, RawFrm, (outs), (ins), "xsha256", []>, A6;
> 
> But it doesn't work. The parser doesn't appear to like the hyphen in
> the instructions.

Comments? Anyone that can help out?

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the llvm-dev mailing list