[Bug] Inductor flop counter reports 0 FLOPs on XPU (get_device_tflops has no non-CUDA fallback)

## Bug Description

`TestSchedulerXPU.test_flop_counter_op` fails on XPU because Inductor's flop
counter reports 0 FLOPs for a compiled `mm` op instead of the expected
non-zero value. The test expects `reference flops == counters`, but on XPU
the recorded flop count is always 0 regardless of dtype.

## Affected Tests

Cases:
op_ut,test/inductor/test_inductor_scheduler.py,TestSchedulerXPU.test_flop_counter_op_options0_xpu_float16
op_ut,test/inductor/test_inductor_scheduler.py,TestSchedulerXPU.test_flop_counter_op_options0_xpu_float32

## Error Message

```
AssertionError: Scalars are not equal!

Expected 0 but got 240.
Absolute difference: 240
Relative difference: inf
op = reference flops = 240 != counters 0
```

## Traceback

```
pytest_command:
pytest test/inductor/test_inductor_scheduler.py -k test_flop_counter_op -v

Traceback:
File "test/inductor/test_inductor_scheduler.py", line 642, in test_flop_counter_op
self.assertEqual(
File ".../torch/testing/_internal/common_utils.py", line 4844, in assertEqual
raise error_metas.pop()[0].to_error( # type: ignore[index]
AssertionError: Scalars are not equal!

Expected 0 but got 240.
Absolute difference: 240
Relative difference: inf
op = reference flops = 240 != counters 0

----------------------------- Captured stderr call -----------------------------
.../torch/_dynamo/pgo.py:605: UserWarning: dynamo_pgo force disabled by torch.compiler.config.force_disable_caches
warn_once(
Autotune Choices Stats:
{"num_choices": 5, "num_triton_choices": 5, "best_kernel": "triton_mm_3", ...}
AUTOTUNE mm(4x5, 5x6)
...
W0807 07:22:23.598000 3197941 site-packages/torch/_inductor/utils.py:3002] [0/0] get_device_tflops: no Triton fallback available for non-CUDA devices. Returning 0.0; roofline estimates will use memory bandwidth only.
I0807 07:22:23.599000 3197941 site-packages/torch/_inductor/compile_fx.py:1784] [0/0] [__inductor_metrics] Graph Metrics:
I0807 07:22:23.599000 3197941 site-packages/torch/_inductor/compile_fx.py:1784] [0/0] [__inductor_metrics] {'num_bytes_accessed': 136, 'nodes_num_elem': [(SchedulerNode(name='op0'), 34)], 'node_runtimes': [(SchedulerNode(name='op0'), 0)]}
```

Both `float16` and `float32` variants fail identically (reference flops = 240,
counters = 0).

## Root Cause Analysis

The warning emitted immediately before the graph metrics are logged is the
key clue: `get_device_tflops: no Triton fallback available for non-CUDA
devices. Returning 0.0; roofline estimates will use memory bandwidth only.`
This is logged from `torch/_inductor/utils.py` (`get_device_tflops`), which
only has a CUDA-specific path for querying device TFLOPS/roofline info via
Triton; for any non-CUDA device (including XPU) it returns `0.0` instead of
querying the actual XPU device's compute throughput. The scheduler's flop
counter for compiled kernels derives its counted FLOPs from this roofline
estimation path, so when `get_device_tflops` returns `0.0` for XPU, the
downstream flop count for the `mm` op is also computed/reported as `0`
instead of the expected `240`. This is a device-generic gap in Inductor's
Triton-based device-info utilities: they assume `is_cuda` and have no XPU
(or other non-CUDA GPU backend) equivalent for querying TFLOPS, so the flop
counter (and other roofline-derived metrics) silently under-report on XPU.

## Related PyTorch Issues

- None found matching `get_device_tflops` non-CUDA fallback for flop counter.

## Related Intel/torch-xpu-ops Issues

- None found (searched "flop_counter", "get_device_tflops flop_counter").

## Versions

Branch: daisyden/inductor (repo: daisyden/pytorch)
Commit: 8f036e818c26e60f0a28fb51e89a5010315a27c3
Platform: linux, Python 3.10.20