Add operation builders

[math-fehr]

Operation build act as create but call the relevant builders for attributes and results.
This improve the number of arguments we can give to our builders, and reduce a bit the boilerplate.
The constructors for operations are also moved to the operation classes, which makes more sense.

[tobiasgrosser]

Thank you Mathieu. Does this PR have test cases that demonstrate the use of this. In another project, I am currently trying to build operations (https://github.com/compiling-techniques/ChocoPyCompiler/pull/76) and the construction of such operations is very verbose. Does this patch help to reduce this verbosity, in particular the need to call get_ssa_value?

RISCVSSA.DIVOp.create(
                    [get_ssa_value(val),
                     get_ssa_value(cst_10)],
                    result_types=[RegisterType()]),

[webmiche]

LGTM. I am really looking forward to using this as well :)

[webmiche]

Do MLIR addis only work on 32bit integers? Maybe add a size argument that has default.

Also, i jus t looked at the MLIR docu, is it possible that simple arithmetic got taken out of std into arith? Maybe we should do the same (or rename them to arith. instead of std.).

[Dinistro]

The type should be a parameter as will, I think.
MLIR is currently refactoring this, so yes, we should probably introduce a arith dialect at some point.

[Dinistro]

Maybe we can make the result_type an optional parameter. 32 bit will be the one type we use most frequently for now, but later on it would be nice to have this flexibility.
On the other hand, one has still access to the Addi.build factory.

[math-fehr]

Yeah, I kept the operation as it was before, but I think we should overall make an additional pass later on the dialects. For example, affine is not up to date at all, and here std is a bit broken.

[webmiche]

(I guess I cannot comment on lines that are too far away from the changed ones)
Maybe add a build to block aswell? from_op_list or from_op_list_and_args.

[math-fehr]

This should be done now!

[math-fehr]

Thank you Mathieu. Does this PR have test cases that demonstrate the use of this. In another project, I am currently trying to build operations (compiling-techniques/ChocoPyCompiler#76) and the construction of such operations is very verbose. Does this patch help to reduce this verbosity, in particular the need to call get_ssa_value?

RISCVSSA.DIVOp.create(
                    [get_ssa_value(val),
                     get_ssa_value(cst_10)],
                    result_types=[RegisterType()]),

Yes, thin gets transformed to

RISCVSSA.DIVOp.build(
                    operands=[val, cst_10],
                    result_types=[RegisterType()]),

and the constructors

        rd = RegisterAttr.get(rd)
        rs1 = RegisterAttr.get(rs1)
        immediate = IntegerAttr.get(immediate)
        return RISCV.LBUOp.create(attributes={
            "rd": rd,
            "rs1": rs1,
            "immediate": immediate
        })

gets replaced by

        immediate = IntegerAttr.build(immediate, 12)
        return RISCV.LBUOp.create(attributes={
            "rd": rd,
            "rs1": rs1,
            "immediate": immediate
        })

[math-fehr]

I added tests for operation builders.
With this, I'll upgrade xdsl to version 0.1 since we introduce multiple breaking changes.
I'll make another PR in the chocopy repo to update everything.

[Dinistro]

This looks good to me.

I think you can merge this and release 0.1. The changes for ChocoPy can be implemented later on, the requirements.txt will still specify the previous version.

[Dinistro]

I honestly do not remember why I selected 64 as a default value here. Is this indeed a good choice?

[Dinistro]

Maybe it would make sense to integrate #29 into the release of 0.1 as well. It will introduce a lot of breaking changes.

[math-fehr]

I removed the default bitwidth for the IntegerAttr attribute. I think I'm done with this branch otherwise, and if this change is okay we can merge it.
Should we also upgrade it to 0.1 since we need wait for the rewriter refactor to integrate #29?

[math-fehr]

Oh, it also seems that yapf just got updated, and that now it add a line skip after a class definition? I'll see if I can disable this for now

[math-fehr]

Or we could also all upgrade to the last yapf version?

[Dinistro]

Upgrading yapf and then merging this branch seems reasonable.

[math-fehr]

Upgrading yapf and then merging this branch seems reasonable.

Oh sorry I modified this too fast, I'll remove this commit

[Dinistro]

Changing it is also not a problem for me. Do whatever you prefer.