Rename DECIMAL_128_FULL and rework usage of TypeSig.gpuNumeric

[kuhushukla]

Partially addresses #3890 , specifically the first two sub-tasks.

[kuhushukla]

build

[kuhushukla]

@revans2 , @sperlingxx thoughts?

[revans2]

I am fine with renaming DECIMAL_128_FULL to DECIMAL_128. It had FULL on it before because I thought we would use it to restrict the maximum precision allowed for things like multiply and divide, but the computation was complicated enough that there is not simple cutoff for most operations.

I do not want to mix GPU and non GPU TypeSig categories. TypeSig.numeric should never be used in a GPU type signature. This is about future proofing things. So if someone adds in a new DECIMAL_256 or something like that in the future we can update one of them and know that it matches the CPU, and not have to worry about it impacting anything on the GPU. It might be nice to rename numeric to be cpuNumberic instead so it is clearer. Again they started out as common, and then when we started to run into decimal situations I separated them, but I didn't want to change the name all at once for backwards compatibility reasons, but I should have.

[kuhushukla]

It might be nice to rename numeric to be cpuNumberic instead so it is clearer.

@revans2 , that makes sense. I can do that here shortly but then based on the comment I think we may just want to keep the occurrences of gpuNumeric + DECIMAL_128 as is. Am I right?

[revans2]

@revans2 , that makes sense. I can do that here shortly but then based on the comment I think we may just want to keep the occurrences of gpuNumeric + DECIMAL_128 as is. Am I right?

I think we have more places that use gpuNumeric + DECIMAL_128 than we do just gpuNumeric. I think it would be cleaner to make gpuNumeric include DECIMAL_128 and then in the few places that cannot support it yet, we can have them create a version for what they do support. And with the latest hashing PR #4470 there should be almost none left.

[kuhushukla]

@revans2 , that makes sense. I can do that here shortly but then based on the comment I think we may just want to keep the occurrences of gpuNumeric + DECIMAL_128 as is. Am I right?

I think we have more places that use gpuNumeric + DECIMAL_128 than we do just gpuNumeric. I think it would be cleaner to make gpuNumeric include DECIMAL_128 and then in the few places that cannot support it yet, we can have them create a version for what they do support. And with the latest hashing PR #4470 there should be almost none left.

Ok yes I also think that makes most sense.

[kuhushukla]

Some places in 320 shims for example the cast operator was missed for decimal 128 which with this change is now covered without any changes to the specific lines in the shims code. Mostly FYI.

[kuhushukla]

build

[kuhushukla]

build

[revans2]

Just one nit.

[kuhushukla]

build