Ryan Taylor via llvm-dev
2017-Feb-15 18:28 UTC
[llvm-dev] Unsigned int displaying as negative
Right, I understand that. So why is 0x7FFF matching fine but not 0x8000 both fit in 16 bit? Thanks. On Wed, Feb 15, 2017 at 1:24 PM, Reid Kleckner <rnk at google.com> wrote:> LLVM IR integers have no sign. You can't reliably tell whether an add or > subtract was signed or unsigned when generating code. > > On Wed, Feb 15, 2017 at 10:19 AM, Ryan Taylor via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I'm curious why 'unsigned short w = 0x8000' is displayed as -32768 in the >> IR? >> >> This propagates to the DAG and hence tablegen, where I am missing >> matching on some immediates because the immediate is not being looked at as >> unsigned? For example, we have no issue if instead of 0x8000 we use 0x7FFF, >> then everything is fine, the match is fine. >> >> I can understand that it's just being printed as 'signed' even when it's >> unsigned due to the bit pattern (2s complement) but it seems to affect >> matching. >> >> We'd like; >> >> unsigned short x, y; >> int main() { >> unsigned short w = 0x8000; >> y = w - x; >> return 0; >> } >> >> To match to something like 'sub16u $0x8000, x, y' (if I set w = 0x7FFF, >> then we get sub16u $0x7FFF, x, y' but not when using 0x8000). >> >> We have some code to determine if the operation is a signed or unsigned >> operation in tablegen. Can anyone suggest a good way to get around this? >> >> Thanks, >> Ryan >> >> _______________________________________________ >> 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/20170215/1ef2d0a2/attachment.html>
Ryan Taylor via llvm-dev
2017-Feb-15 18:30 UTC
[llvm-dev] Unsigned int displaying as negative
Where do in-tree archs handle the difference in this example? The difference being printed either the signed or unsigned value. Thanks. On Wed, Feb 15, 2017 at 1:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:> Right, I understand that. > > So why is 0x7FFF matching fine but not 0x8000 both fit in 16 bit? > > Thanks. > > On Wed, Feb 15, 2017 at 1:24 PM, Reid Kleckner <rnk at google.com> wrote: > >> LLVM IR integers have no sign. You can't reliably tell whether an add or >> subtract was signed or unsigned when generating code. >> >> On Wed, Feb 15, 2017 at 10:19 AM, Ryan Taylor via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> I'm curious why 'unsigned short w = 0x8000' is displayed as -32768 in >>> the IR? >>> >>> This propagates to the DAG and hence tablegen, where I am missing >>> matching on some immediates because the immediate is not being looked at as >>> unsigned? For example, we have no issue if instead of 0x8000 we use 0x7FFF, >>> then everything is fine, the match is fine. >>> >>> I can understand that it's just being printed as 'signed' even when it's >>> unsigned due to the bit pattern (2s complement) but it seems to affect >>> matching. >>> >>> We'd like; >>> >>> unsigned short x, y; >>> int main() { >>> unsigned short w = 0x8000; >>> y = w - x; >>> return 0; >>> } >>> >>> To match to something like 'sub16u $0x8000, x, y' (if I set w = 0x7FFF, >>> then we get sub16u $0x7FFF, x, y' but not when using 0x8000). >>> >>> We have some code to determine if the operation is a signed or unsigned >>> operation in tablegen. Can anyone suggest a good way to get around this? >>> >>> Thanks, >>> Ryan >>> >>> _______________________________________________ >>> 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/20170215/d133e606/attachment.html>
Friedman, Eli via llvm-dev
2017-Feb-15 18:56 UTC
[llvm-dev] Unsigned int displaying as negative
On 2/15/2017 10:30 AM, Ryan Taylor via llvm-dev wrote:> Where do in-tree archs handle the difference in this example? The > difference being printed either the signed or unsigned value. > > Thanks. > > On Wed, Feb 15, 2017 at 1:28 PM, Ryan Taylor <ryta1203 at gmail.com > <mailto:ryta1203 at gmail.com>> wrote: > > Right, I understand that. > > So why is 0x7FFF matching fine but not 0x8000 both fit in 16 bit? > > Thanks. >It's hard to say why your pattern isn't matching without actually seeing the pattern. See imm0_4095 in ARMInstrThumb2.td for an example of the sort of pattern you want. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170215/dc83e2b8/attachment-0001.html>