> Did you test Ada with this patch as that is where the "odd" boolean > types show up? No I haven't tested Ada yet. Since it is work in progress still [WIP]. Quick question, to prevent applying this optimization to those odd Boolean types in Ada, there should be a check to check whether it is canonical boolean type or signed/unsigned, which should prevent messing with odd Boolean types in Ada.
Best wishes, Navid. ________________________________________ From: Andrew Pinski <pins...@gmail.com> Sent: Tuesday, November 23, 2021 11:33 To: Jeff Law Cc: Navid Rahimi; Navid Rahimi via Gcc-patches Subject: [EXTERNAL] Re: [PATCH][WIP] PR tree-optimization/101808 Boolean comparison simplification [You don't often get email from pins...@gmail.com. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.] On Tue, Nov 23, 2021 at 11:15 AM Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > > On 11/23/2021 11:34 AM, Navid Rahimi via Gcc-patches wrote: > > Hi GCC community, > > > > I wanted you take a quick look at this patch to solve this bug [1]. This is > > the code example for the optimization [2] which does include a link to > > proof of each different optimization. > > > > I think it should be possible to use simpler approach than what Andrew has > > used here [3]. > > > > P.S. Tested and verified on Linux x86_64. > > > > 1) > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D101808&data=04%7C01%7Cnavidrahimi%40microsoft.com%7C7b45fdd017874f287caf08d9aeb836ad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637732928490579680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UsE0BbrZpRhrPZZreF%2Bj2spaYmJZuVLc053sWTFG6Ow%3D&reserved=0 > > 2) > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcompiler-explorer.com%2Fz%2FGc448eE3z&data=04%7C01%7Cnavidrahimi%40microsoft.com%7C7b45fdd017874f287caf08d9aeb836ad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637732928490579680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vGlVXyBqBeABvP8hQGb6paYj1t078rSlLdpI0t6qDlc%3D&reserved=0 > > 3) > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D101808%23c1&data=04%7C01%7Cnavidrahimi%40microsoft.com%7C7b45fdd017874f287caf08d9aeb836ad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637732928490579680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DNAyrNo9uZ05FyJYOdc%2BD85Dc9A3VgP95htSfaxRS40%3D&reserved=0 > Don't those match.pd patterns make things worse? We're taking a single > expression evaluation (the conditional) and turning it into two logicals > AFAICT. > > For the !x expression, obviously if x is a constant, then we can > compute that at compile time and we're going from a single conditional > to a single logical which is probably a win, but that's not the case > with this patch AFAICT. One thing is you could use ! to see if bit_not simplifies down to a constant which is what I did in the bug report. But it might be more useful to use the ^ flag (which I added in a different patch) which says the bit_xor is removed then accept it. Note (bit_not @0) is wrong, it should be (bit_xor @0 { booleantrue; } ) as there are boolean types which are signed and/or > 1 precision which is what I had in my patch. Did you test Ada with this patch as that is where the "odd" boolean types show up? Thanks, Andrew Pinski > > jeff