Stack from ghstack (oldest at bottom):

• [EASY] use guard_or_false instead of gso in Meta converter #154234
• -> used guard_or_false instead of guard_size_oblivious inside maybe_reduce #154172
• used guard_or_false instead of guard_size_oblivious in is_int_or_symint #154167
• [EASY] remove guard_size_oblivious from is_nonzero proxy call check #154164
• [EASY] used guard_or_false instead of guard_sizes_oblivious in pointless_view #154154

This was added in #119562
the idea in this loop seems to be the following.

    if (TORCH_GUARD_SIZE_OBLIVIOUS(size.sym_eq(1))) {
      // NB: we could short circuit this once needs_reduce is true but there's
      // no point since the reduction function will guard on this anyway
      if (!c10::guard_or_false(size.sym_eq(target), __FILE__, __LINE__)) {
        needs_reduce = true;
      }
    } else {
      if (!size.sym_eq(target).expect_true(__FILE__, __LINE__)) {
        fail();
      }
    }

1. if we know size ==1
   1.1 : if we know for sure size == target --> no reduce needed.
   1.2 : we know for sure that size != target --> we do reduction.
   1.3: we could not tell if size == target or not --> we do reduction.
2. if we do now know if size ==1 or not
   we add a runtime assertions that size ==target and we fail at runtime if size is not equal to target.

We could have simplified 1.1 and always do reduction under 1.1, since doing 1.3 without runtime checks implies
that it is safe, but i feel the reason could be perf here? idk.

anyway using TORCH_GUARD_OR_FALSE instead of TORCH_GUARD_SIZE_OBLIVIOUS here is appropriate.
there is really no clear reason for size oblivious reasoning. or for this logic not to apply when size is not size like
size is always >=0 anyway. but bad reasoning can make us not able to infer that although we know its true here.

python test/dynamo/test_misc.py -k test_validate_outputs_unbacked