Delete GT_OBJ

[SingleAccretion]

At this point, both GT_BLK and GT_OBJ represent struct loads and are essentially identical in purpose (if not functionality). This change unifies the two as GT_BLK, though I am naturally open to going the other way or choosing a different oper name altogether.

There will be a follow-up which similarly unifies STORE_BLK with STORE_OBJ.

Diffs: one CSE due to the change in gtSetEvalOrder.

A bit of a TP regression on 64 bit because MSVC doesn't inline gtIsLikelyRegVar in the same function, and some perturbance in the switch of fgComputeLifeLIR.

TP breakdown

Base: 1387501711, Diff: 1387934487, +0.0312%
                                                                                                                                                     
Compiler::gtIsLikelyRegVar                                                                        : 487075  : +36.55%  : 41.38% : +0.0351%
Compiler::fgComputeLifeLIR                                                                        : 250001  : +4.47%   : 21.24% : +0.0180%
Compiler::gtNewBlkIndir                                                                           : 32372   : NA       : 2.75%  : +0.0023%
SsaBuilder::RenameDef                                                                             : 10359   : +0.62%   : 0.88%  : +0.0007%
GenTree::OperExceptions                                                                           : 6980    : +0.13%   : 0.59%  : +0.0005%
Compiler::typGetObjLayout                                                                         : 6477    : +59.39%  : 0.55%  : +0.0005%
Compiler::gtNewIndexIndir                                                                         : 2971    : +58.90%  : 0.25%  : +0.0002%
Compiler::optRedundantBranch                                                                      : 2222    : +0.02%   : 0.19%  : +0.0002%
ValueNumStore::VNMap<ValueNumStore::VNDefFuncApp<2>,ValueNumStore::VNDefFuncAppKeyFuncs<2> >::Set : 1563    : +0.03%   : 0.13%  : +0.0001%
Lowering::LowerBlockStore                                                                         : -1420   : -3.77%   : 0.12%  : -0.0001%
ValueNumStore::VNForMapSelectWork                                                                 : -1431   : -0.06%   : 0.12%  : -0.0001%
Compiler::fgMorphSmpOp                                                                            : -3403   : -0.01%   : 0.29%  : -0.0002%
BitSetOps<unsigned __int64 *,1,Compiler *,TrackedVarBitSetTraits>::AssignAllowUninitRhs           : -5127   : -2.37%   : 0.44%  : -0.0004%
Compiler::gtNewStructVal                                                                          : -6541   : -20.75%  : 0.56%  : -0.0005%
ValueNumStore::VNForFuncNoFolding                                                                 : -7804   : -0.13%   : 0.66%  : -0.0006%
ValueNumStore::VNForFunc                                                                          : -10502  : -0.06%   : 0.89%  : -0.0008%
Compiler::fgPerBlockLocalVarLiveness                                                              : -18488  : -0.23%   : 1.57%  : -0.0013%
Compiler::fgValueNumberTree                                                                       : -22890  : -0.23%   : 1.94%  : -0.0016%
Compiler::gtNewObjNode                                                                            : -33337  : -100.00% : 2.83%  : -0.0024%
Compiler::gtSetEvalOrder                                                                          : -257867 : -1.05%   : 21.91% : -0.0186%

[ghost]

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

Issue Details

---

At this point, both GT_BLK and GT_OBJ represent struct loads and are essentially identical in purpose (if not functionality). This change unified the two as GT_BLK, though I am naturally open to going the other way or choosing a different oper name altogether.

There will be a follow-up which similarly unifies STORE_BLK with STORE_OBJ.

Author:	SingleAccretion
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[SingleAccretion]

@dotnet/jit-contrib

[AndyAyersMS]

@SingleAccretion can you resolve the conflicts?

[AndyAyersMS]

@dotnet/jit-contrib anyone planning on reviewing this one?

I will take a look if there are not volunteers.

[AndyAyersMS]

LGTM.

[AndyAyersMS]

Is there a follow-up issue for this?

[AndyAyersMS]

I see that comment just migrated here from the former OBJ case.