Fix for issue #1478

[mihaibudiu]

Unfortunately the stderr is produced by p4test, and not by p4c-bm2-ss.
But when running p4c-bm2-ss on the sample it will produce two warnings:

issue1478-bmv2.p4(25): warning: 3: Size specified for table without keys
        size = 3;
               ^
issue1478-bmv2.p4(35): warning: 10: Size specified for table with constant entries
        size = 10;
               ^^

[antoninbas]

Why not add this to the p4test midend pass manager then?

[antoninbas]

Would it make sense to not make this an inspector and actually replace the size by 0 in that case, so that the backend doesn't have to worry about it?

[mihaibudiu]

Why not just remove the size property rather than replace it by 0?

[antoninbas]

I don't really have a preference. It seems that either way each backend has to be careful. Currently the bmv2 backend unconditionally sets the table size to 1024 when the size is missing (or when the provided size is 0), which seems wrong: https://github.com/p4lang/p4c/blob/master/backends/bmv2/common/control.cpp#L386

[mihaibudiu]

I think that this behavior is inherited from the p4-14 compiler.
The back-end should probably do this only when it is really necessary - i.e., the table size can change dynamically.

[antoninbas]

bmv2 actually enforced fixed table sizes to emulate hardware targets
the default table size code should probably be updated to account for the key size, at least for exact match tables?

[mihaibudiu]

Then let's file a new issue. Probably @hanw is the right person to handle this, since I believe he has ownership of the bmv2-based backends. For constant tables the compiler should somehow measure the table size and tell bmv2 what that is.

[mihaibudiu]

In the meantime it looks to me like deleting the table size for these two cases is the right thing. The back-end is supposed to measure the table anyway. 0 seems a bit arbitrary.