TIR and TensorIR are the same thing. Originally we had TIR that got generated from te after scheduling in te.
Now the same TIR has been extended to include BlockNode to represent blocks, which became a primary data structure to allow scheduling directly on TIR. After scheduling with BlockNode, it gets lowered to the same TIR without Blocks, thus generating a similar final TIR to what we would get from te.
If you’re working with te.compute and basic schedules on that, I’m guessing you’re using te schedule primitives, in which case, you can ignore the TIR block based scheduling.
Scheduling te is still supported, but scheduling with TIR might be preferrable as it contains a lot more scheduling primitives. You could still use te.compute to write the compute, then generate an initial PrimFunc in TIR format with te.create_prim_func. Then you can use TIR scheduling primitives (TIR based primitives are a superset of te schedule primitives, so you should be able to do anything that is already possible in te, with just TIR scheduling).
As for AutoTVM and tuning, there is a bit of history. “AutoTVM” is the original tuning infrastructure added to work with te, which expects the users to define manual templates as guidance for tuning
Then there was the introduction of Ansor, which tried to do more automated tuning based on pre-defined scheduling rules.
Both AutoTVM and Ansor work mostly on TE, as far as I understand.
After TIR based scheduling was introduced, there was the introduction of Metaschedule, which was designed to work with TIR based scheduling and blocks, so if you move to TIR based scheduling, this might be the right thing to explore.