bitintlower: Handle BIT_FIELD_REF load [PR124826]

bitintlower: Handle BIT_FIELD_REF load [PR124826]

The following testcase ends up with a BIT_FIELD_REF from a VECTOR_TYPE union
member to _BitInt(256).  gimple-lower-bitint.cc already contains code to
handle BIT_FIELD_REFs with SSA_NAME first operand to BITINT_TYPE (for
constant index limb access by adjusting the BIT_FIELD_REF to use different
bitsize and index, for variable index (huge _BitInt with limbs accessed in a loop)
by forcing the SSA_NAME into memory), but that doesn't trigger here, because
gimple_assign_load_p predicate is true on it and so it is handled as load
and not BIT_FIELD_REF.  Anyway, the problem is that we end up with
_7 = VIEW_CONVERT_EXPR<unsigned long[4]>(BIT_FIELD_REF <u.v, 256, 0>)[_2];
which tree-cfg.cc verifier doesn't like because BIT_FIELD_REF is not
toplevel reference in there.  The following patch just strips the
BIT_FIELD_REF away if it has zero bit offset, that is the only case I've
managed to reproduce, and in that case we are still later on using VCE to
convert to array and using ARRAY_REF on that.  If offset could be non-zero
but multiple of BITS_PER_UNIT, another approach would be to replace
BIT_FIELD_REF with a MEM_REF.  Anyway, as I haven't managed to reproduce
it with anything but 0, the following patch is enough.

2026-04-14  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/124826
	* gimple-lower-bitint.cc (bitint_large_huge::handle_load): Look through
	BIT_FIELD_REF with zero bit offset.

	* gcc.dg/bitint-128.c: New test.

Reviewed-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>