Check containment for op3 for ternary instruction

[kunalspathak]

Fixes: #111835

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[kunalspathak]

@dotnet/jit-contrib @saucecontrol

[Copilot]

Pull Request Overview

This PR updates the containment logic for op3 in a ternary instruction to correctly account for memory load operations on hardware intrinsics, addressing issue #111835.

• Added a new conditional branch to check if op3 is a contained GT_HWINTRINSIC memory load and use the proper address use builder.
• Retains the previous behavior for RMW and non-contained cases using BuildDelayFreeUses and BuildOperandUses respectively.

[Copilot]

Consider caching the result of op3->AsHWIntrinsic() in a local variable to improve readability and potentially reduce redundant method calls. For example, store the cast result in a variable and then reuse it within the conditional block.

Suggested change

	if (op3->OperIs(GT_HWINTRINSIC) && op3->AsHWIntrinsic()->OperIsMemoryLoad() && op3->isContained())
	{
	srcCount += BuildAddrUses(op3->AsHWIntrinsic()->Op(1), op3RegCandidates);
	auto op3HWIntrinsic = op3->AsHWIntrinsic();
	if (op3->OperIs(GT_HWINTRINSIC) && op3HWIntrinsic->OperIsMemoryLoad() && op3->isContained())
	{
	srcCount += BuildAddrUses(op3HWIntrinsic->Op(1), op3RegCandidates);

[kunalspathak]

@dotnet/jit-contrib ping