[PATCH] Fixing a corner-case bug in lib call optimization

[Gao, Yunzhong]

I was not thinking straight. In the beginning of StrChrOpt::callOptimizer(), there is already this check

to make sure that llvm does not attempt this optimization if char type is not 8-bit long.



FunctionType *FT = Callee->getFunctionType();

if (FT->getNumParams() != 2 ||

     FT->getReturnType() != B.getInt8PtrTy() ||    //<----- "char *" is a pointer to int8

     FT->getParamType(0) != FT->getReturnType() ||

     !FT->getParamType(1)->isIntegerTy(32))

  return 0;



So I guess something like "(255 & value)" should just work.



Thanks,

- Gao.

From: Eli Friedman [mailto:eli.friedman at gmail.com]
Sent: Tuesday, August 13, 2013 2:35 PM
To: Gao, Yunzhong
Cc: Nick Lewycky; reviews+D1279+public+b2efa1ad64fbca2e at llvm-reviews.chandlerc.com; llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] Fixing a corner-case bug in lib call optimization

On Tue, Aug 13, 2013 at 2:03 PM, Gao, Yunzhong <yunzhong_gao at playstation.sony.com<mailto:yunzhong_gao at playstation.sony.com>> wrote:
Hi Nick,
Thanks for reviewing the patch.
I will change the type conversion to "unsigned char" instead; that should make
the result deterministic.
I feel that this is probably still not an ideal solution because the host machine
might have a different size for "char" type than the target machine, but in the
llvm backend I did not find a way to extract the size of target "char" type. I
would guess that machines with non-8-bit bytes are rare nowadays? Since
the patch is only intended for a corner-case comparing a value with zero, it
might suffice using a cast to "unsigned char" or even "(value & 255)".
What do you think?

Assuming char is 8 bits is probably good enough.   You could also extract the relevant type out of the function signature; the first argument to strchr is a char*.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130814/cccbe25e/attachment.html>