1. 08 12月, 2025 2 次提交
  2. 07 12月, 2025 3 次提交
  3. 05 12月, 2025 24 次提交
  4. 04 12月, 2025 1 次提交
  5. 03 12月, 2025 6 次提交
  6. 01 12月, 2025 1 次提交
  7. 29 11月, 2025 1 次提交
  8. 28 11月, 2025 2 次提交
    • Ricardo Vieira's avatar
      Do not recreate Scalar Ops with custom TransferType for Elemwise inplacing · ae499a49
      Ricardo Vieira 提交于
      This helper could arbitrarily override the default output_type from `ScalarOp.make_node` so that the output type matched one of the input types.
      This can be used to create artificial Op signatures that don't make sense or can't be cleanly implemented in other backends. For instance an Add with signature (int8,int64)->int8.
      
      This helper was historically used in:
       1. Elemwise inplace rewrite. I assume as a preventive measure. However, regular use should never require changing the ScalarOp signature, as we only try to inplace on inputs that match the output dtype and recreating the same Op with the same input types should always return the same output type. ScalarOp don't have a concept of inplace, only the Elemwise wrapper does, and it shouldn't require recreating/mutating the original Op.
       2. SecondOp. Here it makes sense, but a custom static_method works just as well
       3. Inplace tests with the inplace variants of `@scalar_elemwise` decorator. These test Classes were removed. It still didn't make sense to test/force Ops to have an artifical signature for the sake of tests. They were removed anyway
      ae499a49
    • Ricardo Vieira's avatar
      e0a2a865