Position of constant folded operand in or-statement affects codegen

In the code below, placing the comparison with Environment.NewLine inline after a non-runtime constant check produces extra code compared to hoisting the newline check to a local, or placing it first.

x86: https://godbolt.org/z/oeMWrEWje
arm: https://godbolt.org/z/EY3f8cscG

using System;

static class B
{
    public static bool Hoisted(byte v)
    {
        bool isUnix = Environment.NewLine != "\r\n";
        return (v == 2 && isUnix);
    }

    public static bool Inline_Before(byte v)
    {
        return (Environment.NewLine != "\r\n" && v == 2);
    }

    public static bool Inline_After(byte v)
    {
        return (v == 2 && Environment.NewLine != "\r\n");
    }
}

x86 example:

// expected
       cmp      dil, 2
       sete     al
       movzx    rax, al
       ret      

// actual
       cmp      dil, 2
       je       SHORT G_M4495_IG05
       xor      eax, eax
       ret      
G_M4495_IG05:  ;; offset=0x0009
       mov      eax, 1
       ret

@EgorBo

Hi @EgorBo @JulieLeeMSFT, thank you for triaging this issue!

I'd like to work on this and submit a PR. From my initial investigation, the constant folding itself works correctly in all three cases (the Environment.NewLine check is fully eliminated). The difference is that in the Inline_After case, the remaining BBJ_COND block with v == 2 isn't being simplified into a branchless return (sete/movzx), unlike the Hoisted and Inline_Before cases. I plan to enable JITDUMP to trace exactly where the optimization gap occurs — likely around fgFoldCondToReturnBlock or the block compaction between morph and optOptimizeBools.

Please let me know if there are any pointers or context I should be aware of before diving in.